<pre>Internet Research Task Force (IRTF)                         S. Symington
Request for Comments: 6257                         The MITRE Corporation
Category: Experimental                                        S. Farrell
ISSN: 2070-1721                                   Trinity College Dublin
                                                                H. Weiss
                                                               P. Lovell
                                                            SPARTA, Inc.
                                                                May 2011


                 <span class="h1">Bundle Security Protocol Specification</span>

Abstract

   This document defines the bundle security protocol, which provides
   data integrity and confidentiality services for the Bundle Protocol.
   Separate capabilities are provided to protect the bundle payload and
   additional data that may be included within the bundle.  We also
   describe various security considerations including some policy
   options.

   This document is a product of the Delay-Tolerant Networking Research
   Group and has been reviewed by that group.  No objections to its
   publication as an RFC were raised.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Research Task
   Force (IRTF).  The IRTF publishes the results of Internet-related
   research and development activities.  These results might not be
   suitable for deployment.  This RFC represents the consensus of the
   Delay-Tolerant Networking Research Group of the Internet Research
   Task Force (IRTF).  Documents approved for publication by the IRSG
   are not a candidate for any level of Internet Standard; see <a href="./rfc5741#section-2">Section&nbsp;2
   of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6257">http://www.rfc-editor.org/info/rfc6257</a>.







<span class="grey">Symington, et al.             Experimental                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.








































<span class="grey">Symington, et al.             Experimental                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
      <a href="#section-1.1">1.1</a>. Related Documents ..........................................<a href="#page-4">4</a>
      <a href="#section-1.2">1.2</a>. Terminology ................................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Security Blocks .................................................<a href="#page-8">8</a>
      <a href="#section-2.1">2.1</a>. Abstract Security Block ....................................<a href="#page-9">9</a>
      <a href="#section-2.2">2.2</a>. Bundle Authentication Block ...............................<a href="#page-13">13</a>
      <a href="#section-2.3">2.3</a>. Payload Integrity Block ...................................<a href="#page-15">15</a>
      <a href="#section-2.4">2.4</a>. Payload Confidentiality Block .............................<a href="#page-16">16</a>
      <a href="#section-2.5">2.5</a>. Extension Security Block ..................................<a href="#page-20">20</a>
      <a href="#section-2.6">2.6</a>. Parameters and Result Fields ..............................<a href="#page-21">21</a>
      <a href="#section-2.7">2.7</a>. Key Transport .............................................<a href="#page-23">23</a>
      <a href="#section-2.8">2.8</a>. PIB and PCB Combinations ..................................<a href="#page-24">24</a>
   <a href="#section-3">3</a>. Security Processing ............................................<a href="#page-25">25</a>
      <a href="#section-3.1">3.1</a>. Nodes as Policy Enforcement Points ........................<a href="#page-26">26</a>
      <a href="#section-3.2">3.2</a>. Processing Order of Security Blocks .......................<a href="#page-26">26</a>
      <a href="#section-3.3">3.3</a>. Security Regions ..........................................<a href="#page-29">29</a>
      <a href="#section-3.4">3.4</a>. Canonicalization of Bundles ...............................<a href="#page-31">31</a>
      <a href="#section-3.5">3.5</a>. Endpoint ID Confidentiality ...............................<a href="#page-37">37</a>
      <a href="#section-3.6">3.6</a>. Bundles Received from Other Nodes .........................<a href="#page-38">38</a>
      <a href="#section-3.7">3.7</a>. The At-Most-Once-Delivery Option ..........................<a href="#page-39">39</a>
      <a href="#section-3.8">3.8</a>. Bundle Fragmentation and Reassembly .......................<a href="#page-40">40</a>
      <a href="#section-3.9">3.9</a>. Reactive Fragmentation ....................................<a href="#page-41">41</a>
      <a href="#section-3.10">3.10</a>. Attack Model .............................................<a href="#page-42">42</a>
   <a href="#section-4">4</a>. Mandatory Ciphersuites .........................................<a href="#page-42">42</a>
      <a href="#section-4.1">4.1</a>. BAB-HMAC ..................................................<a href="#page-42">42</a>
      <a href="#section-4.2">4.2</a>. PIB-RSA-SHA256 ............................................<a href="#page-43">43</a>
      <a href="#section-4.3">4.3</a>. PCB-RSA-AES128-PAYLOAD-PIB-PCB ............................<a href="#page-44">44</a>
      <a href="#section-4.4">4.4</a>. ESB-RSA-AES128-EXT ........................................<a href="#page-48">48</a>
   <a href="#section-5">5</a>. Key Management .................................................<a href="#page-51">51</a>
   <a href="#section-6">6</a>. Default Security Policy ........................................<a href="#page-51">51</a>
   <a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-53">53</a>
   <a href="#section-8">8</a>. Conformance ....................................................<a href="#page-55">55</a>
   <a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-56">56</a>
      <a href="#section-9.1">9.1</a>. Bundle Block Types ........................................<a href="#page-56">56</a>
      <a href="#section-9.2">9.2</a>. Ciphersuite Numbers .......................................<a href="#page-56">56</a>
      <a href="#section-9.3">9.3</a>. Ciphersuite Flags .........................................<a href="#page-56">56</a>
      <a href="#section-9.4">9.4</a>. Parameters and Results ....................................<a href="#page-57">57</a>
   <a href="#section-10">10</a>. References ....................................................<a href="#page-58">58</a>
      <a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-58">58</a>
      <a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-59">59</a>









<span class="grey">Symington, et al.             Experimental                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document defines security features for the Bundle Protocol
   [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>] intended for use in delay-tolerant networks, in order to
   provide Delay-Tolerant Networking (DTN) security services.

   The Bundle Protocol is used in DTNs that overlay multiple networks,
   some of which may be challenged by limitations such as intermittent
   and possibly unpredictable loss of connectivity, long or variable
   delay, asymmetric data rates, and high error rates.  The purpose of
   the Bundle Protocol is to support interoperability across such
   stressed networks.  The Bundle Protocol is layered on top of
   underlay-network-specific convergence layers, on top of network-
   specific lower layers, to enable an application in one network to
   communicate with an application in another network, both of which are
   spanned by the DTN.

   Security will be important for the Bundle Protocol.  The stressed
   environment of the underlying networks over which the Bundle Protocol
   will operate makes it important for the DTN to be protected from
   unauthorized use, and this stressed environment poses unique
   challenges for the mechanisms needed to secure the Bundle Protocol.
   Furthermore, DTNs may very likely be deployed in environments where a
   portion of the network might become compromised, posing the usual
   security challenges related to confidentiality, integrity, and
   availability.

   Different security processing applies to the payload and extension
   blocks that may accompany it in a bundle, and different rules apply
   to various extension blocks.

   This document describes both the base Bundle Security Protocol (BSP)
   and a set of mandatory ciphersuites.  A ciphersuite is a specific
   collection of various cryptographic algorithms and implementation
   rules that are used together to provide certain security services.

   The Bundle Security Protocol applies, by definition, only to those
   nodes that implement it, known as "security-aware" nodes.  There MAY
   be other nodes in the DTN that do not implement BSP.  All nodes can
   interoperate with the exception that BSP security operations can only
   happen at security-aware nodes.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Related Documents</span>

   This document is best read and understood within the context of the
   following other DTN documents:





<span class="grey">Symington, et al.             Experimental                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


      "Delay-Tolerant Networking Architecture" [<a href="#ref-DTNarch" title="&quot;Delay-Tolerant Networking Architecture&quot;">DTNarch</a>] defines the
      architecture for delay-tolerant networks, but does not discuss
      security at any length.

      The DTN Bundle Protocol [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>] defines the format and processing
      of the blocks used to implement the Bundle Protocol, excluding the
      security-specific blocks defined here.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Terminology</span>

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

   We introduce the following terminology for purposes of clarity:

      source - the bundle node from which a bundle originates

      destination - the bundle node to which a bundle is ultimately
      destined

      forwarder - the bundle node that forwarded the bundle on its most
      recent hop

      intermediate receiver or "next hop" - the neighboring bundle node
      to which a forwarder forwards a bundle.

      path - the ordered sequence of nodes through which a bundle passes
      on its way from source to destination

   In the figure below, which is adapted from figure 1 in the Bundle
   Protocol Specification [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>], four bundle nodes (denoted BN1, BN2,
   BN3, and BN4) reside above some transport layer(s).  Three distinct
   transport and network protocols (denoted T1/N1, T2/N2, and T3/N3) are
   also shown.















<span class="grey">Symington, et al.             Experimental                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   +---------v-|   +-&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;v-+     +-&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;v-+   +-^---------+
   | BN1     v |   | ^   BN2   v |     | ^   BN3   v |   | ^  BN4    |
   +---------v-+   +-^---------v-+     +-^---------v-+   +-^---------+
   | T1      v |   + ^  T1/T2  v |     + ^  T2/T3  v |   | ^  T3     |
   +---------v-+   +-^---------v-+     +-^---------v +   +-^---------+
   | N1      v |   | ^  N1/N2  v |     | ^  N2/N3  v |   | ^  N3     |
   +---------v-+   +-^---------v +     +-^---------v-+   +-^---------+
   |         &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;^         &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;^         &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;^         |
   +-----------+   +------------+      +-------------+   +-----------+
   |                     |                    |                      |
   |&lt;--  An Internet ---&gt;|                    |&lt;--- An Internet  ---&gt;|
   |                     |                    |                      |

   BN = "Bundle Node" as defined in the Bundle Protocol Specification

            Figure 1: Bundle Nodes Sit at the Application Layer
                           of the Internet Model

   Bundle node BN1 originates a bundle that it forwards to BN2.  BN2
   forwards the bundle to BN3, and BN3 forwards the bundle to BN4.  BN1
   is the source of the bundle and BN4 is the destination of the bundle.
   BN1 is the first forwarder, and BN2 is the first intermediate
   receiver; BN2 then becomes the forwarder, and BN3 the intermediate
   receiver; BN3 then becomes the last forwarder, and BN4 the last
   intermediate receiver, as well as the destination.

   If node BN2 originates a bundle (for example, a bundle status report
   or a custodial signal), which is then forwarded on to BN3, and then
   to BN4, then BN2 is the source of the bundle (as well as being the
   first forwarder of the bundle) and BN4 is the destination of the
   bundle (as well as being the final intermediate receiver).

   We introduce the following security-specific DTN terminology:

      security-source - a bundle node that adds a security block to a
      bundle

      security-destination - a bundle node that processes a security
      block of a bundle

      security path - the ordered sequence of security-aware nodes
      through which a bundle passes on its way from the security-source
      to the security-destination








<span class="grey">Symington, et al.             Experimental                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   Referring to Figure 1 again:

   If the bundle that originates at BN1 is given a security block by
   BN1, then BN1 is the security-source of this bundle with respect to
   that security block, as well as being the source of the bundle.

   If the bundle that originates at BN1 is given a security block by
   BN2, then BN2 is the security-source of this bundle with respect to
   that security block, even though BN1 is the source.

   If the bundle that originates at BN1 is given a security block by BN1
   that is intended to be processed by BN3, then BN1 is the security-
   source and BN3 is the security-destination with respect to this
   security block.  The security path for this block is BN1 to BN3.

   A bundle MAY have multiple security blocks.  The security-source of a
   bundle, with respect to a given security block in the bundle, MAY be
   the same as or different from the security-source of the bundle with
   respect to a different security block in the bundle.  Similarly, the
   security-destination of a bundle, with respect to each of that
   bundle's security blocks, MAY be the same or different.  Therefore,
   the security paths for various blocks MAY be, and often will be,
   different.

   If the bundle that originates at BN1 is given a security block by BN1
   that is intended to be processed by BN3, and BN2 adds a security
   block with security-destination BN4, the security paths for the two
   blocks overlap but not completely.  This problem is discussed further
   in <a href="#section-3.3">Section 3.3</a>.

   As required in [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>], forwarding nodes MUST transmit blocks in a
   bundle in the same order in which they were received.  This
   requirement applies to all DTN nodes, not just ones that implement
   security processing.  Blocks in a bundle MAY be added or deleted
   according to the applicable specification, but those blocks that are
   both received and transmitted MUST be transmitted in the same order
   that they were received.

   If a node is not security-aware, then it forwards the security blocks
   in the bundle unchanged unless the bundle's block processing flags
   specify otherwise.  If a network has some nodes that are not
   security-aware, then the block processing flags SHOULD be set such
   that security blocks are not discarded at those nodes solely because
   they cannot be processed there.  Except for this, the non-security-
   aware nodes are transparent relay points and are invisible as far as
   security processing is concerned.





<span class="grey">Symington, et al.             Experimental                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   The block sequence also indicates the order in which certain
   significant actions have affected the bundle, and therefore the
   sequence in which actions MUST occur in order to produce the bundle
   at its destination.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Security Blocks</span>

   There are four types of security blocks that MAY be included in a
   bundle.  These are the Bundle Authentication Block (BAB), the Payload
   Integrity Block (PIB), the Payload Confidentiality Block (PCB), and
   the Extension Security Block (ESB).

      The BAB is used to ensure the authenticity and integrity of the
      bundle along a single hop from forwarder to intermediate receiver.
      Since security blocks are only processed at security-aware nodes,
      a "single hop" from a security-aware forwarder to the next
      security-aware intermediate receiver might be more than one actual
      hop.  This situation is discussed further in <a href="#section-2.2">Section 2.2</a>.

      The PIB is used to ensure the authenticity and integrity of the
      payload from the PIB security-source, which creates the PIB, to
      the PIB security-destination, which verifies the PIB
      authenticator.  The authentication information in the PIB MAY (if
      the ciphersuite allows) be verified by any node in between the PIB
      security-source and the PIB security-destination that has access
      to the cryptographic keys and revocation status information
      required to do so.

      Since a BAB protects a bundle on a "hop-by-hop" basis and other
      security blocks MAY be protecting over several hops or end-to-end,
      whenever both are present, the BAB MUST form the "outer" layer of
      protection -- that is, the BAB MUST always be calculated and added
      to the bundle after all other security blocks have been calculated
      and added to the bundle.

      The PCB indicates that the payload has been encrypted, in whole or
      in part, at the PCB security-source in order to protect the bundle
      content while in transit to the PCB security-destination.

      PIB and PCB protect the payload and are regarded as "payload-
      related" for purposes of the security discussion in this document.
      Other blocks are regarded as "non-payload" blocks.  Of course, the
      primary block is unique and has separate rules.

      The ESB provides security for non-payload blocks in a bundle.
      Therefore, ESB is not applied to PIBs or PCBs and, of course, is
      not appropriate for either the payload block or primary block.




<span class="grey">Symington, et al.             Experimental                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   Each of the security blocks uses the Canonical Bundle Block Format as
   defined in the Bundle Protocol Specification.  That is, each security
   block is comprised of the following elements:

   o  Block-type code

   o  Block processing control flags

   o  Block EID-reference list (OPTIONAL)

   o  Block data length

   o  Block-type-specific data fields

   Since the four security blocks have most fields in common, we can
   shorten the description of the Block-type-specific data fields of
   each security block if we first define an abstract security block
   (ASB) and then specify each of the real blocks in terms of the fields
   that are present/absent in an ASB.  Note that no bundle ever contains
   an actual ASB, which is simply a specification artifact.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Abstract Security Block</span>

   Many of the fields below use the "SDNV" type defined in [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>].
   SDNV stands for Self-Delimiting Numeric Value.

   An ASB consists of the following mandatory and optional fields:

   o  Block-type code (one byte) - as in all bundle protocol blocks
      except the primary bundle block.  The block-type codes for the
      security blocks are:

         BundleAuthenticationBlock - BAB: 0x02

         PayloadIntegrityBlock - PIB: 0x03

         PayloadConfidentialityBlock - PCB: 0x04

         ExtensionSecurityBlock - ESB: 0x09

   o  Block processing control flags (SDNV) - defined as in all bundle
      protocol blocks except the primary bundle block (as described in
      the Bundle Protocol Specification [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>]).  SDNV encoding is
      described in the Bundle Protocol.  There are no general
      constraints on the use of the block processing control flags, and
      some specific requirements are discussed later.





<span class="grey">Symington, et al.             Experimental                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   o  EID-references - composite field defined in [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>] containing
      references to one or two endpoint identifiers (EIDs).  Presence of
      the EID-reference field is indicated by the setting of the "Block
      contains an EID-reference field" (EID_REF) bit of the block
      processing control flags.  If one or more references are present,
      flags in the ciphersuite ID field, described below, specify which.

      If no EID fields are present, then the composite field itself MUST
      be omitted entirely and the EID_REF bit MUST be unset.  A count
      field of zero is not permitted.

   o  The possible EIDs are:

      *  (OPTIONAL) Security-source - specifies the security-source for
         the block.  If this is omitted, then the source of the bundle
         is assumed to be the security-source unless otherwise
         indicated.

      *  (OPTIONAL) Security-destination - specifies the security-
         destination for the block.  If this is omitted, then the
         destination of the bundle is assumed to be the security-
         destination unless otherwise indicated.

      If two EIDs are present, security-source is first and security-
      destination comes second.

   o  Block data length (SDNV) - as in all bundle protocol blocks except
      the primary bundle block.  SDNV encoding is described in the
      Bundle Protocol.

   o  Block-type-specific data fields as follows:

      *  Ciphersuite ID (SDNV)

      *  Ciphersuite flags (SDNV)

      *  (OPTIONAL) Correlator - when more than one related block is
         inserted, then this field MUST have the same value in each
         related block instance.  This is encoded as an SDNV.  See the
         note in <a href="#section-3.8">Section 3.8</a> with regard to correlator values in bundle
         fragments.

      *  (OPTIONAL) Ciphersuite-parameters - compound field of the next
         two items

         +  Ciphersuite-parameters length - specifies the length of the
            following Ciphersuite-parameters data field and is encoded
            as an SDNV.



<span class="grey">Symington, et al.             Experimental                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


         +  Ciphersuite-parameters data - parameters to be used with the
            ciphersuite in use, e.g., a key identifier or initialization
            vector (IV).  See <a href="#section-2.6">Section 2.6</a> for a list of potential
            parameters and their encoding rules.  The particular set of
            parameters that is included in this field is defined as part
            of the ciphersuite specification.

      *  (OPTIONAL) Security-result - compound field of the next two
         items

         +  Security-result length - contains the length of the next
            field and is encoded as an SDNV.

         +  Security-result data - contains the results of the
            appropriate ciphersuite-specific calculation (e.g., a
            signature, Message Authentication Code (MAC), or ciphertext
            block key).

   Although the diagram hints at a 32-bit layout, this is purely for the
   purpose of exposition.  Except for the "type" field, all fields are
   variable in length.

   +----------------+----------------+----------------+----------------+
   | type           |  flags (SDNV)  |  EID-ref list(comp)             |
   +----------------+----------------+----------------+----------------+
   | length (SDNV)                   |  ciphersuite (SDNV)             |
   +----------------+----------------+----------------+----------------+
   | ciphersuite flags (SDNV)        |  correlator  (SDNV)             |
   +----------------+----------------+----------------+----------------+
   |params len(SDNV)| ciphersuite params data                          |
   +----------------+----------------+----------------+----------------+
   |res-len (SDNV)  | security-result data                             |
   +----------------+----------------+----------------+----------------+

                Figure 2: Abstract Security Block Structure

   Some ciphersuites are specified in <a href="#section-4">Section 4</a>, which also specifies
   the rules that MUST be satisfied by ciphersuite specifications.
   Additional ciphersuites MAY be defined in separate specifications.
   Ciphersuite IDs not specified are reserved.  Implementations of the
   Bundle Security Protocol decide which ciphersuites to support,
   subject to the requirements of <a href="#section-4">Section 4</a>.  It is RECOMMENDED that
   implementations that allow additional ciphersuites permit ciphersuite
   ID values at least up to and including 127, and they MAY decline to
   allow larger ID values.






<span class="grey">Symington, et al.             Experimental                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   The structure of the ciphersuite flags field is shown in Figure 3.
   In each case, the presence of an optional field is indicated by
   setting the value of the corresponding flag to one.  A value of zero
   indicates the corresponding optional field is missing.  Presently,
   there are five flags defined for the field; for convenience, these
   are shown as they would be extracted from a single-byte SDNV.  Future
   additions may cause the field to grow to the left so, as with the
   flags fields defined in [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>], the description below numbers the
   bit positions from the right rather than the standard RFC definition,
   which numbers bits from the left.

      src - bit 4 indicates whether the EID-reference field of the ASB
      contains the optional reference to the security-source.

      dest - bit 3 indicates whether the EID-reference field of the ASB
      contains the optional reference to the security-destination.

      parm - bit 2 indicates whether or not the ciphersuite-parameters
      length and ciphersuite-parameters data fields are present.

      corr - bit 1 indicates whether or not the ASB contains an optional
      correlator.

      res - bit 0 indicates whether or not the ASB contains the
      security-result length and security-result data fields.

      bits 5-6 are reserved for future use.

   Bit   Bit   Bit   Bit   Bit   Bit   Bit
    6     5     4     3     2     1     0
   +-----+-----+-----+-----+-----+-----+-----+
   | reserved  | src |dest |parm |corr |res  |
   +-----+-----+-----+-----+-----+-----+-----+

            Figure 3: Ciphersuite Flags

   A little bit more terminology: if the block is a PIB, when we refer
   to the PIB-source, we mean the security-source for the PIB as
   represented by the EID-reference in the EID-reference field.
   Similarly, we may refer to the "PCB-dest", meaning the security-
   destination of the PCB, again as represented by an EID reference.
   For example, referring to Figure 1 again, if the bundle that
   originates at BN1 is given a Payload Confidentiality Block (PCB) by
   BN1 that is protected using a key held by BN3, and it is given a
   Payload Integrity Block (PIB) by BN1, then BN1 is both the PCB-source
   and the PIB-source of the bundle, and BN3 is the PCB-destination of
   the bundle.




<span class="grey">Symington, et al.             Experimental                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   The correlator field is used to associate several related instances
   of a security block.  This can be used to place a BAB that contains
   the ciphersuite information at the "front" of a (probably large)
   bundle, and another correlated BAB that contains the security-result
   at the "end" of the bundle.  This allows even very memory-constrained
   nodes to be able to process the bundle and verify the BAB.  There are
   similar use cases for multiple related instances of PIB and PCB as
   will be seen below.

   The ciphersuite specification MUST make it clear whether or not
   multiple block instances are allowed, and if so, under what
   conditions.  Some ciphersuites can, of course, leave flexibility to
   the implementation, whereas others might mandate a fixed number of
   instances.

   For convenience, we use the term "first block" to refer to the
   initial block in a group of correlated blocks or to the single block
   if there are no others in the set.  Obviously, there can be several
   unrelated groups in a bundle, each containing only one block or more
   than one, and each having its own "first block".

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Bundle Authentication Block</span>

   In this section, we describe typical BAB field values for two
   scenarios -- where a single instance of the BAB contains all the
   information and where two related instances are used, one "up front",
   which contains the ciphersuite, and another following the payload,
   which contains the security-result (e.g., a MAC).

   For the case where a single BAB is used:

      The block-type code field value MUST be 0x02.

      The block processing control flags value can be set to whatever
      values are required by local policy.  Ciphersuite designers should
      carefully consider the effect of setting flags that either discard
      the block or delete the bundle in the event that this block cannot
      be processed.

      The ciphersuite ID MUST be documented as a hop-by-hop
      authentication-ciphersuite that requires one instance of the BAB.

      The correlator field MUST NOT be present.

      The ciphersuite-parameters field MAY be present, if so specified
      in the ciphersuite specification.





<span class="grey">Symington, et al.             Experimental                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


      An EID-reference to the security-source MAY be present.  The
      security-source can also be specified as part of key-information
      described in <a href="#section-2.6">Section 2.6</a> or another block such as the Previous-Hop
      Insertion Block [<a href="#ref-PHIB" title="&quot;Delay-Tolerant Networking Previous-Hop Insertion Block&quot;">PHIB</a>].  The security-source might also be
      inferred from some implementation-specific means such as the
      convergence layer.

      An EID-reference to the security-destination MAY be present and is
      useful to ensure that the bundle has been forwarded to the correct
      next-hop node.

      The security-result MUST be present as it is effectively the
      "output" from the ciphersuite calculation (e.g., the MAC or
      signature) applied to the (relevant parts of the) bundle (as
      specified in the ciphersuite definition).

   For the case using two related BAB instances, the first instance is
   as defined above, except the ciphersuite ID MUST be documented as a
   hop-by-hop authentication ciphersuite that requires two instances of
   the BAB.  In addition, the correlator MUST be present and the
   security-result length and security-result fields MUST be absent.
   The second instance of the BAB MUST have the same correlator value
   present and MUST contain security-result length and security-result
   data fields.  The other optional fields MUST NOT be present.
   Typically, this second instance of a BAB will be the last block of
   the bundle.

   The details of key transport for BAB are specified by the particular
   ciphersuite.  In the absence of conflicting requirements, the
   following should be noted by implementors:

   o  the key-information item in <a href="#section-2.6">Section 2.6</a> is OPTIONAL, and if not
      provided, then the key SHOULD be inferred from the source-
      destination tuple, being the previous key used, a key created from
      a key-derivation function, or a pre-shared key.

   o  if all the nodes are security-aware, the capabilities of the
      underlying convergence layer might be useful for identifying the
      security-source.

   o  depending upon the key mechanism used, bundles can be signed by
      the sender, or authenticated for one or more recipients, or both.









<span class="grey">Symington, et al.             Experimental                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Payload Integrity Block</span>

   A PIB is an ASB with the following additional restrictions:

      The block-type code value MUST be 0x03.

      The block processing control flags value can be set to whatever
      values are required by local policy.  Ciphersuite designers should
      carefully consider the effect of setting flags that either discard
      the block or delete the bundle in the event that this block cannot
      be processed.

      The ciphersuite ID MUST be documented as an end-to-end
      authentication-ciphersuite or as an end-to-end error-detection-
      ciphersuite.

      The correlator MUST be present if the ciphersuite requires that
      more than one related instance of a PIB be present in the bundle.
      The correlator MUST NOT be present if the ciphersuite only
      requires one instance of the PIB in the bundle.

      The ciphersuite-parameters field MAY be present.

      An EID-reference to the security-source MAY be present.  The
      security-source can also be specified as part of key-information
      described in <a href="#section-2.6">Section 2.6</a>.

      An EID-reference to the security-destination MAY be present.

      The security-result is effectively the "output" from the
      ciphersuite calculation (e.g., the MAC or signature) applied to
      the (relevant parts of the) bundle.  As in the case of the BAB,
      this field MUST be present if the correlator is absent.  If more
      than one related instance of the PIB is required, then this is
      handled in the same way as described for the BAB above.

      The ciphersuite MAY process less than the entire original bundle
      payload.  This might be because it is defined to process some
      subset of the bundle, or perhaps because the current payload is a
      fragment of an original bundle.  For whatever reason, if the
      ciphersuite processes less than the complete, original bundle
      payload, the ciphersuite-parameters of this block MUST specify
      which bytes of the bundle payload are protected.








<span class="grey">Symington, et al.             Experimental                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   For some ciphersuites, (e.g., those using asymmetric keying to
   produce signatures or those using symmetric keying with a group key),
   the security information can be checked at any hop on the way to the
   security-destination that has access to the required keying
   information.  This possibility is further discussed in <a href="#section-3.6">Section 3.6</a>.

   The use of a generally available key is RECOMMENDED if custodial
   transfer is employed and all nodes SHOULD verify the bundle before
   accepting custody.

   Most asymmetric PIB ciphersuites will use the PIB-source to indicate
   who the signer is and will not require the PIB-dest field because the
   key needed to verify the PIB authenticator will be a public key
   associated with the PIB-source.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Payload Confidentiality Block</span>

   A typical confidentiality ciphersuite will encrypt the payload using
   a randomly generated bundle encrypting key (BEK) and will use a key-
   information item in the PCB security-parameters to carry the BEK
   encrypted with some long-term key encryption key (KEK) or well-known
   public key.  If neither the destination nor security-destination
   resolves the key to use for decryption, the key-information item in
   the ciphersuite-parameters field can also be used to indicate the
   decryption key with which the BEK can be recovered.  If the bundle
   already contains PIBs and/or PCBs, these SHOULD also be encrypted
   using this same BEK, as described just below for "super-encryption".
   The encrypted block is encapsulated into a new PCB that replaces the
   original block at the same place in the bundle.

   It is strongly RECOMMENDED that a data integrity mechanism be used in
   conjunction with confidentiality, and that encryption-only
   ciphersuites NOT be used.  AES-Galois/Counter Mode (AES-GCM)
   satisfies this requirement.  The "authentication tag" or "integrity
   check value" is stored into the security-result rather than being
   appended to the payload as is common in some protocols since, as
   described below, it is important that there be no change in the size
   of the payload.

   The payload is encrypted "in-place", that is, following encryption,
   the payload block payload field contains ciphertext, not plaintext.
   The payload block processing control flags are unmodified.

   The "in-place" encryption of payload bytes is to allow bundle payload
   fragmentation and reassembly, and custody transfer, to operate
   without knowledge of whether or not encryption has occurred and, if
   so, how many times.




<span class="grey">Symington, et al.             Experimental                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   Fragmentation, reassembly, and custody transfer are adversely
   affected by a change in size of the payload due to ambiguity about
   what byte range of the original payload is actually in any particular
   fragment.  Ciphersuites SHOULD place any payload expansion, such as
   authentication tags (integrity check values) and any padding
   generated by a block-mode cipher, into an integrity check value item
   in the security-result field (see <a href="#section-2.6">Section 2.6</a>) of the confidentiality
   block.

   Payload super-encryption is allowed, that is, encrypting a payload
   that has already been encrypted, perhaps more than once.
   Ciphersuites SHOULD define super-encryption such that, as well as re-
   encrypting the payload, it also protects the parameters of earlier
   encryption.  Failure to do so may represent a vulnerability in some
   circumstances.

   Confidentiality is normally applied to the payload, and possibly to
   additional blocks.  It is RECOMMENDED to apply a Payload
   Confidentiality ciphersuite to non-payload blocks only if these
   SHOULD be super-encrypted with the payload.  If super-encryption of
   the block is not desired, then protection of the block SHOULD be done
   using the Extension Security Block mechanism rather than PCB.

   Multiple related PCB instances are required if both the payload and
   PIBs and PCBs in the bundle are to be encrypted.  These multiple PCB
   instances require correlators to associate them with each other since
   the key-information is provided only in the first PCB.

   There are situations where more than one PCB instance is required but
   the instances are not "related" in the sense that requires
   correlators.  One example is where a payload is encrypted for more
   than one security-destination so as to be robust in the face of
   routing uncertainties.  In this scenario, the payload is encrypted
   using a BEK.  Several PCBs contain the BEK encrypted using different
   KEKs, one for each destination.  These multiple PCB instances are not
   "related" and SHOULD NOT contain correlators.

   The ciphersuite MAY apply different rules to confidentiality for non-
   payload blocks.

   A PCB is an ASB with the following additional restrictions:

      The block-type code value MUST be 0x04.

      The block processing control flags value can be set to whatever
      values are required by local policy, except that a PCB "first
      block" MUST have the "replicate in every fragment" flag set.  This
      flag SHOULD NOT be set otherwise.  Ciphersuite designers should



<span class="grey">Symington, et al.             Experimental                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


      carefully consider the effect of setting flags that either discard
      the block or delete the bundle in the event that this block cannot
      be processed.

      The ciphersuite ID MUST be documented as a confidentiality
      ciphersuite.

      The correlator MUST be present if there is more than one related
      PCB instance.  The correlator MUST NOT be present if there are no
      related PCB instances.

      If a correlator is present, the key-information MUST be placed in
      the PCB "first block".

      Any additional bytes generated as a result of encryption and/or
      authentication processing of the payload SHOULD be placed in an
      "integrity check value" field (see <a href="#section-2.6">Section 2.6</a>) in the security-
      result of the first PCB.

      The ciphersuite-parameters field MAY be present.

      An EID-reference to the security-source MAY be present.  The
      security-source can also be specified as part of key-information
      described in <a href="#section-2.6">Section 2.6</a>.

      An EID-reference to the security-destination MAY be present.

      The security-result MAY be present and normally contains fields
      such as an encrypted bundle encryption key, authentication tag, or
      the encrypted versions of bundle blocks other than the payload
      block.

   The ciphersuite MAY process less than the entire original bundle
   payload, either because the current payload is a fragment of the
   original bundle or just because it is defined to process some subset.
   For whatever reason, if the ciphersuite processes less than the
   complete, original bundle payload, the "first" PCB MUST specify, as
   part of the ciphersuite-parameters, which bytes of the bundle payload
   are protected.

   PCB ciphersuites MUST specify which blocks are to be encrypted.  The
   specification MAY be flexible and be dependent upon block type,
   security policy, various data values, and other inputs, but it MUST
   be deterministic.  The determination of whether or not a block is to
   be encrypted MUST NOT be ambiguous.






<span class="grey">Symington, et al.             Experimental                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   As was the case for the BAB and PIB, if the ciphersuite requires more
   than one instance of the PCB, then the "first block" MUST contain any
   optional fields (e.g., security-destination, etc.) that apply to all
   instances with this correlator.  These MUST be contained in the first
   instance and MUST NOT be repeated in other correlated blocks.  Fields
   that are specific to a particular instance of the PCB MAY appear in
   that PCB.  For example, security-result fields MAY (and probably
   will) be included in multiple related PCB instances, with each result
   being specific to that particular block.  Similarly, several PCBs
   might each contain a ciphersuite-parameters field with an IV specific
   to that PCB instance.

   Put another way: when confidentiality will generate multiple blocks,
   it MUST create a "first" PCB with the required ciphersuite ID,
   parameters, etc., as specified above.  Typically, this PCB will
   appear early in the bundle.  This "first" PCB contains the parameters
   that apply to the payload and also to the other correlated PCBs.  The
   correlated PCBs follow the "first" PCB and MUST NOT repeat the
   ciphersuite-parameters, security-source, or security-destination
   fields from the first PCB.  These correlated PCBs need not follow
   immediately after the "first" PCB, and probably will not do so.  Each
   correlated block, encapsulating an encrypted PIB or PCB, is at the
   same place in the bundle as the original PIB or PCB.

   A ciphersuite MUST NOT mix payload data and a non-payload block in a
   single PCB.

   Even if a to-be-encrypted block has the "discard" flag set, whether
   or not the PCB's "discard" flag is set is an implementation/policy
   decision for the encrypting node.  (The "discard" flag is more
   properly called the "Discard if block can't be processed" flag.)

   Any existing EID-list in the to-be-encapsulated original block
   remains exactly as-is, and is copied to become the EID-list for the
   replacing block.  The encapsulation process MUST NOT replace or
   remove the existing EID-list entries.  This is critically important
   for correct updating of entries at the security-destination.

   At the security-destination, either the specific destination or the
   bundle-destination, the processes described above are reversed.  The
   payload is decrypted "in-place" using the salt, IV, and key values in
   the first PCB, including verification using the ICV.  These values
   are described in <a href="#section-2.6">Section 2.6</a>.  Each correlated PCB is also processed
   at the same destination, using the salt and key values from the first
   PCB and the block-specific IV item.  The encapsulated block item in
   the security-result is decrypted and validated, using also the tag
   that SHOULD have been appended to the ciphertext of the original
   block data.  Assuming the validation succeeds, the resultant



<span class="grey">Symington, et al.             Experimental                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   plaintext, which is the entire content of the original block,
   replaces the PCB at the same place in the bundle.  The block type
   reverts to that of the original block prior to encapsulation, and the
   other block-specific data fields also return to their original
   values.  Implementors are cautioned that this "replacement" process
   requires delicate stitchery, as the EID-list contents in the
   decapsulated block are invalid.  As noted above, the EID-list
   references in the original block were preserved in the "replacing"
   PCB, and will have been updated as necessary as the bundle has toured
   the DTN.  The references from the PCB MUST replace the references
   within the EID-list of the newly decapsulated block.  Caveat
   implementor.

<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>.  Extension Security Block</span>

   Extension security blocks provide protection for non-payload-related
   portions of a bundle.  ESBs MUST NOT be used for the primary block or
   payload, including payload-related security blocks (PIBs and PCBs).

   It is sometimes desirable to protect certain parts of a bundle in
   ways other than those applied to the bundle payload.  One such
   example is bundle metadata that might specify the kind of data in the
   payload but not the actual payload detail, as described in [<a href="#ref-DTNMD" title="&quot;Delay-Tolerant Networking Metadata Extension Block&quot;">DTNMD</a>].

   ESBs are typically used to apply confidentiality protection.  While
   it is possible to create an integrity-only ciphersuite, the block
   protection is not transparent and makes access to the data more
   difficult.  For simplicity, this discussion describes the use of a
   confidentiality ciphersuite.

   The protection mechanisms in ESBs are similar to other security
   blocks with two important differences:

   o  different key values are used (using the same key as that for
      payload would defeat the purpose)

   o  the block is not encrypted or super-encrypted with the payload

   A typical ESB ciphersuite will encrypt the extension block using a
   randomly generated ephemeral key and will use the key-information
   item in the security-parameters field to carry the key encrypted with
   some long-term key encryption key (KEK) or well-known public key.  If
   neither the destination nor security-destination resolves the key to
   use for decryption, the key-information item in the ciphersuite-
   parameters field can be used also to indicate the decryption key with
   which the BEK can be recovered.





<span class="grey">Symington, et al.             Experimental                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   It is strongly RECOMMENDED that a data integrity mechanism be used in
   conjunction with confidentiality, and that encryption-only
   ciphersuites NOT be used.  AES-GCM satisfies this requirement.

   The ESB is placed in the bundle in the same position as the block
   being protected.  That is, the entire original block is processed
   (encrypted, etc.) and encapsulated in a "replacing" ESB-type block,
   and this appears in the bundle at the same sequential position as the
   original block.  The processed data is placed in the security-result
   field.

   The process is reversed at the security-destination with the
   recovered plaintext block replacing the ESB that had encapsulated it.
   Processing of EID-list entries, if any, is described in <a href="#section-2.4">Section 2.4</a>,
   and this MUST be followed in order to correctly recover EIDs.

   An ESB is an ASB with the following additional restrictions:

      The block type is 0x09.

      Ciphersuite flags indicate which fields are present in this block.
      Ciphersuite designers should carefully consider the effect of
      setting flags that either discard the block or delete the bundle
      in the event that this block cannot be processed.

      EID-references MUST be stored in the EID-reference list.

      The security-source MAY be present.  The security-source can also
      be specified as part of key-information described in <a href="#section-2.6">Section 2.6</a>.
      If neither is present, then the bundle-source is used as the
      security-source.

      The security-destination MAY be present.  If not present, then the
      bundle-destination is used as the security-destination.

   The security-parameters MAY optionally contain a block-type code
   field to indicate the type of the encapsulated block.  Since this
   replicates a field in the encrypted portion of the block, it is a
   slight security risk, and its use is therefore OPTIONAL.

<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>.  Parameters and Result Fields</span>

   Various ciphersuites include several items in the security-parameters
   and/or security-result fields.  Which items MAY appear is defined by
   the particular ciphersuite description.  A ciphersuite MAY support
   several instances of the same type within a single block.





<span class="grey">Symington, et al.             Experimental                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   Each item is represented as a type-length-value.  Type is a single
   byte indicating which item this is.  Length is the count of data
   bytes to follow, and is an SDNV-encoded integer.  Value is the data
   content of the item.

   Item types are

      0: reserved

      1: initialization vector (IV)

      2: reserved

      3: key-information

      4: fragment-range (offset and length as a pair of SDNVs)

      5: integrity signature

      6: unassigned

      7: salt

      8: PCB integrity check value (ICV)

      9: reserved

      10: encapsulated block

      11: block type of encapsulated block

      12 - 191: reserved

      192 - 250: private use

      251 - 255: reserved

   The following descriptions apply to the usage of these items for all
   ciphersuites.  Additional characteristics are noted in the discussion
   for specific suites.

   o  initialization vector (IV): random value, typically eight to
      sixteen bytes.

   o  key-information: key material encoded or protected by the key
      management system and used to transport an ephemeral key protected
      by a long-term key.  This item is discussed further in
      <a href="#section-2.7">Section 2.7</a>.



<span class="grey">Symington, et al.             Experimental                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   o  fragment-range: pair of SDNV values (offset then length)
      specifying the range of payload bytes to which a particular
      operation applies.  This is termed "fragment-range" since that is
      its typical use, even though sometimes it describes a subset range
      that is not a fragment.  The offset value MUST be the offset
      within the original bundle, which might not be the offset within
      the current bundle if the current bundle is already a fragment.

   o  integrity signature: result of BAB or PIB digest or signing
      operation.  This item is discussed further in <a href="#section-2.7">Section 2.7</a>.

   o  salt: an IV-like value used by certain confidentiality suites.

   o  PCB integrity check value (ICV): output from certain
      confidentiality ciphersuite operations to be used at the
      destination to verify that the protected data has not been
      modified.

   o  encapsulated block: result of confidentiality operation on certain
      blocks, contains the ciphertext of the block and MAY also contain
      an integrity check value appended to the ciphertext; MAY also
      contain padding if required by the encryption mode; used for non-
      payload blocks only.

   o  block type of encapsulated block: block-type code for a block that
      has been encapsulated in ESB.

<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>.  Key Transport</span>

   This specification endeavors to maintain separation between the
   security protocol and key management.  However, these two interact in
   the transfer of key-information, etc., from security-source to
   security-destination.  The intent of the separation is to facilitate
   the use of a variety of key management systems without needing to
   tailor a ciphersuite to each individually.

   The key management process deals with such things as long-term keys,
   specifiers for long-term keys, certificates for long-term keys, and
   integrity signatures using long-term keys.  The ciphersuite itself
   SHOULD NOT require a knowledge of these, and separation is improved
   if it treats these as opaque entities to be handled by the key
   management process.

   The key management process deals specifically with the content of two
   of the items defined in <a href="#section-2.6">Section 2.6</a>: key-information (item type 3)
   and integrity signature (item type 5).  The ciphersuite MUST define
   the details and format for these items.  To facilitate




<span class="grey">Symington, et al.             Experimental                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   interoperability, it is strongly RECOMMENDED that the implementations
   use the appropriate definitions from the Cryptographic Message Syntax
   (CMS) [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>] and related RFCs.

   Many situations will require several pieces of key-information.
   Again, ciphersuites MUST define whether they accept these packed into
   a single key-information item and/or separated into multiple
   instances of key-information.  For interoperability, it is
   RECOMMENDED that ciphersuites accept these packed into a single key-
   information item, and that they MAY additionally choose to accept
   them sent as separate items.

<span class="h3"><a class="selflink" id="section-2.8" href="#section-2.8">2.8</a>.  PIB and PCB Combinations</span>

   Given the above definitions, nodes are free to combine applications
   of PIB and PCB in any way they wish -- the correlator value allows
   for multiple applications of security services to be handled
   separately.  Since PIB and PCB apply to the payload and ESB to non-
   payload blocks, combinations of ESB with PIB and/or PCB are not
   considered.

   There are some obvious security problems that could arise when
   applying multiple services.  For example, if we encrypted a payload
   but left a PIB security-result containing a signature in the clear,
   payload guesses could be confirmed.

   We cannot, in general, prevent all such problems since we cannot
   assume that every ciphersuite definition takes account of every other
   ciphersuite definition.  However, we can limit the potential for such
   problems by requiring that any ciphersuite that applies to one
   instance of a PIB or PCB MUST be applied to all instances with the
   same correlator.

   We now list the PIB and PCB combinations that we envisage as being
   useful to support:

      Encrypted tunnels - a single bundle MAY be encrypted many times en
      route to its destination.  Clearly, it has to be decrypted an
      equal number of times, but we can imagine each encryption as
      representing the entry into yet another layer of tunnel.  This is
      supported by using multiple instances of PCB, but with the payload
      encrypted multiple times, "in-place".  Depending upon the
      ciphersuite definition, other blocks can and should be encrypted,
      as discussed above and in <a href="#section-2.4">Section 2.4</a> to ensure that parameters
      are protected in the case of super-encryption.






<span class="grey">Symington, et al.             Experimental                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


      Multiple parallel authenticators - a single security-source might
      wish to protect the integrity of a bundle in multiple ways.  This
      could be required if the bundle's path is unpredictable and if
      various nodes might be involved as security-destinations.
      Similarly, if the security-source cannot determine in advance
      which algorithms to use, then using all might be reasonable.  This
      would result in uses of PIB that, presumably, all protect the
      payload, and which cannot in general protect one another.  Note
      that this logic can also apply to a BAB, if the unpredictable
      routing happens in the convergence layer, so we also envisage
      support for multiple parallel uses of BAB.

      Multiple sequential authenticators - if some security-destination
      requires assurance about the route that bundles have taken, then
      it might insist that each forwarding node add its own PIB.  More
      likely, however, would be that outbound "bastion" nodes would be
      configured to sign bundles as a way of allowing the sending
      "domain" to take accountability for the bundle.  In this case, the
      various PIBs will likely be layered, so that each protects the
      earlier applications of PIB.

      Authenticated and encrypted bundles - a single bundle MAY require
      both authentication and confidentiality.  Some specifications
      first apply the authenticator and follow this by encrypting the
      payload and authenticator.  As noted previously in the case where
      the authenticator is a signature, there are security reasons for
      this ordering.  (See the PCB-RSA-AES128-PAYLOAD-PIB-PCB
      ciphersuite defined in <a href="#section-4.3">Section 4.3</a>.)  Others apply the
      authenticator after encryption, that is, to the ciphertext.  This
      ordering is generally RECOMMENDED and minimizes attacks that, in
      some cases, can lead to recovery of the encryption key.

   There are, no doubt, other valid ways to combine PIB and PCB
   instances, but these are the "core" set supported in this
   specification.  Having said that, as will be seen, the mandatory
   ciphersuites defined here are quite specific and restrictive in terms
   of limiting the flexibility offered by the correlator mechanism.
   This is primarily designed to keep this specification as simple as
   possible, while at the same time supporting the above scenarios.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Security Processing</span>

   This section describes the security aspects of bundle processing.








<span class="grey">Symington, et al.             Experimental                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Nodes as Policy Enforcement Points</span>

   All nodes are REQUIRED to have and enforce their own configurable
   security policies, whether these policies be explicit or default, as
   defined in <a href="#section-6">Section 6</a>.

   All nodes serve as Policy Enforcement Points (PEPs) insofar as they
   enforce polices that MAY restrict the permissions of bundle nodes to
   inject traffic into the network.  Policies MAY apply to traffic that
   originates at the current node, traffic that terminates at the
   current node, and traffic that is to be forwarded by the current node
   to other nodes.  If a particular transmission request, originating
   either locally or remotely, satisfies the node's policy or policies
   and is therefore accepted, then an outbound bundle can be created and
   dispatched.  If not, then in its role as a PEP, the node will not
   create or forward a bundle.  Error handling for such cases is
   currently considered out of scope for this document.

   Policy enforcing code MAY override all other processing steps
   described here and elsewhere in this document.  For example, it is
   valid to implement a node that always attempts to attach a PIB.
   Similarly, it is also valid to implement a node that always rejects
   all requests that imply the use of a PIB.

   Nodes MUST consult their security policy to determine the criteria
   that a received bundle ought to meet before it will be forwarded.
   These criteria MUST include a determination of whether or not the
   received bundle MUST include a valid BAB, PIB, PCB, or ESB.  If the
   bundle does not meet the node's policy criteria, then the bundle MUST
   be discarded and processed no further; in this case, a bundle status
   report indicating the failure MAY be generated.

   The node's policy MAY call for the node to add or subtract some
   security blocks.  For example, it might require that the node attempt
   to encrypt (parts of) the bundle for some security-destination or
   that it add a PIB.  If the node's policy requires a BAB to be added
   to the bundle, it MUST be added last so that the calculation of its
   security-result MAY take into consideration the values of all other
   blocks in the bundle.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Processing Order of Security Blocks</span>

   The processing order of security actions for a bundle is critically
   important for the actions to complete successfully.  In general, the
   actions performed at the originating node MUST be executed in the
   reverse sequence at the destination.  There are variations and
   exceptions, and these are noted below.




<span class="grey">Symington, et al.             Experimental                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   The sequence is maintained in the ordering of security blocks in the
   bundle.  It is for this reason that blocks MUST NOT be rearranged at
   forwarding nodes, whether or not they support the security protocols.
   The only blocks that participate in this ordering are the primary and
   payload blocks, and the PIB and PCB security blocks themselves.  All
   other extension blocks, including ESBs, are ignored for purposes of
   determining the processing order.

   The security blocks are added to and removed from a bundle in a last-
   in-first-out (LIFO) manner, with the top of the stack immediately
   after the primary block.  A newly created bundle has just the primary
   and payload blocks, and the stack is empty.  As security actions are
   requested for the bundle, security blocks are pushed onto the stack
   immediately after the primary block.  The early actions have security
   blocks close to the payload, later actions have blocks nearer to the
   primary block.  The actions deal with only those blocks in the bundle
   at the time, so, for example, the first to be added processes only
   the payload and primary blocks, the next might process the first if
   it chooses and the payload and primary, and so on.  The last block to
   be added can process all the blocks.

   When the bundle is received, this process is reversed and security
   processing begins at the top of the stack, immediately after the
   primary block.  The security actions are performed, and the block is
   popped from the stack.  Processing continues with the next security
   block until finally only the payload and primary blocks remain.

   The simplicity of this description is undermined by various real-
   world requirements.  Nonetheless, it serves as a helpful initial
   framework for understanding the bundle security process.

   The first issue is a very common one and easy to handle.  The bundle
   may be sent indirectly to its destination, requiring several
   forwarding hops to finally arrive there.  Security processing happens
   at each node, assuming that the node supports bundle security.  For
   the following discussion, we assume that a bundle is created and that
   confidentiality, then payload integrity, and finally bundle
   authentication are applied to it.  The block sequence would therefore
   be primary-BAB-PIB-PCB-payload.  Traveling from source to destination
   requires going through one intermediate node, so the trip consists of
   two hops.

   When the bundle is received at the intermediate node, the receive
   processing validates the BAB and pops it from the stack.  However,
   the PIBs and PCBs have the final destination as their security-
   destination, so these cannot be processed and removed.  The
   intermediate node then begins the send process with the four
   remaining blocks in the bundle.  The outbound processing adds any



<span class="grey">Symington, et al.             Experimental                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   security blocks required by local policy, and these are pushed on the
   stack immediately after the primary block, ahead of the PIB.  In this
   example, the intermediate node adds a PIB as a signature that the
   bundle has passed through the node.

   The receive processing at the destination first handles the
   intermediate node's PIB and pops it, next is the originator's PIB,
   also popped, and finally the originator's confidentiality block that
   allows the payload to be decrypted and the bundle handled for
   delivery.

   In practice, DTNs are likely to be more complex.  The security policy
   for a node specifies the security requirements for a bundle.  The
   policy will possibly cause one or more security operations to be
   applied to the bundle at the current node, each with its own
   security-destination.  Application of policy at subsequent nodes
   might cause additional security operations, each with a security-
   destination.  The list of security-destinations in the security
   blocks (BAB, PIB and PCB, not ESB) creates a partial-ordering of
   nodes that MUST be visited en route to the bundle-destination.

   The bundle security scheme does not deal with security paths that
   overlap partially but not completely.  The security policy for a node
   MUST avoid specifying, for a bundle, a security-destination that
   causes a conflict with any existing security-destination in that
   bundle.  This is discussed further in <a href="#section-3.3">Section 3.3</a>.

   The second issue relates to the reversibility of certain security
   process actions.  In general, the actions fall into two categories:
   those that do not affect other parts of the bundle and those that are
   fully reversible.  Creating a bundle signature, for example, does not
   change the bundle content except for the result.  The encryption
   performed as part of the confidentiality processing does change the
   bundle, but the reverse processing at the destination restores the
   original content.

   The third category is the one where the bundle content has changed
   slightly and in a non-destructive way, but there is no mechanism to
   reverse the change.  The simplest example is the addition of an EID-
   reference to a security block.  The addition of the reference causes
   the text to be added to the bundle's dictionary.  The text may also
   be used by other references, so removal of the block and this
   specific EID-reference does not cause removal of the text from the
   dictionary.  This shortcoming is of no impact to the "sequential" or
   "wrapping" security schemes described above, but does cause failures
   with "parallel" authentication mechanisms.  Solutions for this





<span class="grey">Symington, et al.             Experimental                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   problem are implementation specific and typically involve multi-pass
   processing such that blocks are added at one stage and the security-
   results calculated at a later stage of the overall process.

   Certain ciphersuites have sequence requirements for their correct
   operation, most notably the bundle authentication ciphersuites.
   Processing for bundle authentication is required to happen after all
   other sending operations, and prior to any receive operations at the
   next-hop node.  Therefore, it follows that BABs MUST always be pushed
   onto the stack after all others.

   Although we describe the security block list as a stack, there are
   some blocks that are placed after the payload and therefore are not
   part of the stack.  The BundleAuthentication ciphersuite #1 ("BA1")
   requires a second, correlated block to contain the security-result,
   and this block is placed after the payload, usually as the last block
   in the bundle.  We can apply the stack rules even to these blocks by
   specifying that they be added to the end of the bundle at the same
   time that their "owner" or "parent" block is pushed on the stack.  In
   fact, they form a stack beginning at the payload but growing in the
   other direction.  Also, not all blocks in the main stack have a
   corresponding entry in the trailing stack.  The only blocks that MUST
   follow the payload are those mandated by ciphersuites as correlated
   blocks for holding a security-result.  No other blocks are required
   to follow the payload block and it is NOT RECOMMENDED that they do
   so.

   ESBs are effectively placeholders for the blocks they encapsulate
   and, since those do not form part of the processing sequence
   described above, ESBs themselves do not either.  ESBs MAY be
   correlated, however, so the "no reordering" requirement applies to
   them as well.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Security Regions</span>

   Each security block has a security path, as described in the
   discussion for Figure 1, and the paths for various blocks are often
   different.

   BABs are always for a single hop, and these restricted paths never
   cause conflict.

   The paths for PIBs and PCBs are often from bundle-source to bundle-
   destination, to provide end-to-end protection.  A bundle-source-to-
   bundle-destination path likewise never causes a problem.

   Another common scenario is for gateway-to-gateway protection of
   traffic between two sub-networks ("tunnel-mode").



<span class="grey">Symington, et al.             Experimental                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   Looking at Figure 1 and the simplified version shown in Figure 4, we
   can regard BN2 and BN3 as gateways connecting the two sub-networks
   labeled "An internet".  As long as they provide security for the BN2-
   BN3 path, all is well.  Problems begin, for example, when BN2 adds
   blocks with BN4 as the security-destination, and the originating node
   BN1 has created blocks with BN3 as security-destination.  We now have
   two paths, and neither is a subset of the other.

   This scenario should be prevented by node BN2's security policy being
   aware of the already existing block with BN3 as the security-
   destination.  This policy SHOULD NOT specify a security-destination
   that is further distant than any existing security-destination.

   +---------v-|   +-&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;v-+     +-&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;v-+   +-^---------+
   | BN1     v |   | ^   BN2   v |     | ^   BN3   v |   | ^  BN4    |
   +---------v-+   +-^---------v-+     +-^---------v-+   +-^---------+
             &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;^         &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;^         &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;^

    &lt;-------------  BN1 to BN3 path  ------------&gt;

                       &lt;-------------  BN2 to BN4 path  ------------&gt;

                   Figure 4: Overlapping Security Paths

   Consider the case where the security concern is for data integrity,
   so the blocks are PIBs.  BN1 creates one ("PIa") along with the new
   bundle, and BN2 pushes its own PIB "PIb" on the stack, with security-
   destination BN4.  When this bundle arrives at BN3, the bundle blocks
   are

   primary - PIb - PIa - payload

   Block PIb is not destined for this node BN3, so it has to be
   forwarded.  This is the security-destination for block PIa so, after
   validation, it should be removed from the bundle; however, that will
   invalidate the PIb signature when the block is checked at the final
   destination.  The PIb signature includes the primary block, PIb
   itself, PIa and the payload block, so PIa MUST remain in the bundle.
   This is why security blocks are treated as a stack and add/remove
   operations are permitted only at the top-of-stack.

   The situation would be worse if the security concern is
   confidentiality, and PCBs are employed, using the confidentiality
   ciphersuite #3 ("PC3") described in <a href="#section-4.3">Section 4.3</a>.  In this scenario,
   BN1 would encrypt the bundle with BN3 as security-destination, BN2
   would create an overlapping security path by super-encrypting the
   payload and encapsulating the PC3 block for security-destination BN4.
   BN3 forwards all the blocks without change.  BN4 decrypts the payload



<span class="grey">Symington, et al.             Experimental                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   from its super-encryption and decapsulates the PC3 block, only to
   find that it should have been processed earlier.  Assuming that BN4
   has no access to BN3's key store, BN4 has no way to decrypt the
   bundle and recover the original content.

   As mentioned above, authors of security policy need to use care to
   ensure that their policies do not cause overlaps.  These guidelines
   should prove helpful.

      The originator of a bundle can always specify the bundle-
      destination as the security-destination and should be cautious
      about doing otherwise.

      In the "tunnel-mode" scenario where two sub-networks are connected
      by a tunnel through a network, the gateways can each specify the
      other as security-destination and should be cautious about doing
      otherwise.

      BAB is never a problem because it is always only a single hop.

      PIB for a bundle without PCB will usually specify the bundle-
      destination as security-destination.

      PIB for a bundle containing a PCB should specify as its security-
      destination the security-destination of the PCB (outermost PCB if
      there are more than one).

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Canonicalization of Bundles</span>

   In order to verify a signature or MAC on a bundle, the exact same
   bits, in the exact same order, MUST be input to the calculation upon
   verification as were input upon initial computation of the original
   signature or MAC value.  Consequently, a node MUST NOT change the
   encoding of any URI [<a href="./rfc3986" title="&quot;Uniform Resource Identifier (URI): Generic Syntax&quot;">RFC3986</a>] in the dictionary field, e.g., changing
   the DNS part of some HTTP URL from lower case to upper case.  Because
   bundles MAY be modified while in transit (either correctly or due to
   implementation errors), a canonical form of any given bundle (that
   contains a BAB or PIB) MUST be defined.

   This section defines bundle canonicalization algorithms used in
   Sections <a href="#section-4.1">4.1</a> and <a href="#section-4.2">4.2</a> ciphersuites.  Other ciphersuites can use these
   or define their own canonicalization procedures.









<span class="grey">Symington, et al.             Experimental                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>.  Strict Canonicalization</span>

   The first algorithm that can be used permits no changes at all to the
   bundle between the security-source and the security-destination.  It
   is mainly intended for use in BAB ciphersuites.  This algorithm
   conceptually catenates all blocks in the order presented, but omits
   all security-result data fields in blocks of this ciphersuite type.
   That is, when a BAB ciphersuite specifies this algorithm, we omit all
   BAB security-results for all BAB ciphersuites.  When a PIB
   ciphersuite specifies this algorithm, we omit all PIB security-
   results for all PIB ciphersuites.  All security-result length fields
   are included, even though their corresponding security-result data
   fields are omitted.

   Notes:

   o  In the above, we specify that security-result data is omitted.
      This means that no bytes of the security-result data are input.
      We do not set the security-result length to zero.  Rather, we
      assume that the security-result length will be known to the module
      that implements the ciphersuite before the security-result is
      calculated, and require that this value be in the security-result
      length field even though the security-result data itself will be
      omitted.

   o  The 'res' bit of the ciphersuite ID, which indicates whether or
      not the security-result length and security-result data field are
      present, is part of the canonical form.

   o  The value of the block data length field, which indicates the
      length of the block, is also part of the canonical form.  Its
      value indicates the length of the entire bundle when the bundle
      includes the security-result data field.

   o  BABs are always added to bundles after PIBs, so when a PIB
      ciphersuite specifies this strict canonicalization algorithm and
      the PIB is received with a bundle that also includes one or more
      BABs, application of strict canonicalization as part of the PIB
      security-result verification process requires that all BABs in the
      bundle be ignored entirely.

<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>.  Mutable Canonicalization</span>

   This algorithm is intended to protect parts of the bundle that SHOULD
   NOT be changed in transit.  Hence, it omits the mutable parts of the
   bundle.





<span class="grey">Symington, et al.             Experimental                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   The basic approach is to define a canonical form of the primary block
   and catenate it with the security (PIBs and PCBs only) and payload
   blocks in the order that they will be transmitted.  This algorithm
   ignores all other blocks, including ESBs, because it cannot be
   determined whether or not they will change as the bundle transits the
   network.  In short, this canonicalization protects the payload,
   payload-related security blocks, and parts of the primary block.

   Many fields in various blocks are stored as variable-length SDNVs.
   These are canonicalized in unpacked form, as eight-byte fixed-width
   fields in network byte order.  The size of eight bytes is chosen
   because implementations MAY handle larger values as invalid, as noted
   in [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>].

   The canonical form of the primary block is shown in Figure 5.
   Essentially, it de-references the dictionary block, adjusts lengths
   where necessary, and ignores flags that MAY change in transit.


































<span class="grey">Symington, et al.             Experimental                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   +----------------+----------------+----------------+----------------+
   |    Version     |      Processing flags (incl. COS and  SRR)       |
   +----------------+----------------+---------------------------------+
   |                Canonical primary block length                     |
   +----------------+----------------+---------------------------------+
   |                Destination endpoint ID length                     |
   +----------------+----------------+---------------------------------+
   |                                                                   |
   |                      Destination endpoint ID                      |
   |                                                                   |
   +----------------+----------------+---------------------------------+
   |                    Source endpoint ID length                      |
   +----------------+----------------+----------------+----------------+
   |                                                                   |
   |                        Source endpoint ID                         |
   |                                                                   |
   +----------------+----------------+---------------------------------+
   |                  Report-to endpoint ID length                     |
   +----------------+----------------+----------------+----------------+
   |                                                                   |
   |                      Report-to endpoint ID                        |
   |                                                                   |
   +----------------+----------------+----------------+----------------+
   |                                                                   |
   +                    Creation Timestamp (2 x SDNV)                  +
   |                                                                   |
   +---------------------------------+---------------------------------+
   |                             Lifetime                              |
   +----------------+----------------+----------------+----------------+

         Figure 5: The Canonical Form of the Primary Bundle Block

   The fields shown in Figure 5 are as follows:

      The version value is the single-byte value in the primary block.

      The processing flags value in the primary block is an SDNV, and
      includes the class-of-service (COS) and status report request
      (SRR) fields.  For purposes of canonicalization, the SDNV is
      unpacked into a fixed-width field, and some bits are masked out.
      The unpacked field is ANDed with mask 0x0000 0000 0007 C1BE to set
      to zero all reserved bits and the "bundle is a fragment" bit.

      The canonical primary block length value is a four-byte value
      containing the length (in bytes) of this structure, in network
      byte order.





<span class="grey">Symington, et al.             Experimental                     [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


      The destination endpoint ID length and value are the length (as a
      four-byte value in network byte order) and value of the
      destination endpoint ID from the primary bundle block.  The URI is
      simply copied from the relevant part(s) of the dictionary block
      and is not itself canonicalized.  Although the dictionary entries
      contain "null-terminators", the null-terminators are not included
      in the length or the canonicalization.

      The source endpoint ID length and value are handled similarly to
      the destination.

      The report-to endpoint ID length and value are handled similarly
      to the destination.

      The creation timestamp (2 x SDNV) and lifetime (SDNV) are simply
      copied from the primary block, with the SDNV values being
      represented as eight-byte unpacked values.

      Fragment offset and total application data unit length are
      ignored, as is the case for the "bundle is a fragment" bit
      mentioned above.  If the payload data to be canonicalized is less
      than the complete, original bundle payload, the offset and length
      are specified in the security-parameters.

   For non-primary blocks being included in the canonicalization, the
   block processing control flags value used for canonicalization is the
   unpacked SDNV value with reserved and mutable bits masked to zero.
   The unpacked value is ANDed with mask 0x0000 0000 0000 0077 to zero
   reserved bits and the "last block" flag.  The "last block" flag is
   ignored because BABs and other security blocks MAY be added for some
   parts of the journey but not others, so the setting of this bit might
   change from hop to hop.

   Endpoint ID references in security blocks are canonicalized using the
   de-referenced text form in place of the reference pair.  The
   reference count is not included, nor is the length of the endpoint ID
   text.

   The block-length is canonicalized as an eight-byte unpacked value in
   network byte order.  If the payload data to be canonicalized is less
   than the complete, original bundle payload, this field contains the
   size of the data being canonicalized (the "effective block") rather
   that the actual size of the block.








<span class="grey">Symington, et al.             Experimental                     [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   Payload blocks are generally canonicalized as-is, with the exception
   that, in some instances, only a portion of the payload data is to be
   protected.  In such a case, only those bytes are included in the
   canonical form, and additional ciphersuite-parameters are required to
   specify which part of the payload is protected, as discussed further
   below.

   Security blocks are handled likewise, except that the ciphersuite
   will likely specify that the "current" security block security-result
   field not be considered part of the canonical form.  This differs
   from the strict canonicalization case since we might use the mutable
   canonicalization algorithm to handle sequential signatures such that
   signatures cover earlier ones.

   ESBs MUST NOT be included in the canonicalization.

   Notes:

   o  The canonical form of the bundle is not transmitted.  It is simply
      an artifact used as input to digesting.

   o  We omit the reserved flags because we cannot determine if they
      will change in transit.  The masks specified above will have to be
      revised if additional flags are defined and they need to be
      protected.

   o  Our URI encoding does not preserve the null-termination convention
      from the dictionary field, nor do we separate the scheme and the
      scheme-specific part (SSP) as is done there.

   o  The URI encoding will cause errors if any node rewrites the
      dictionary content (e.g., changing the DNS part of an HTTP URL
      from lower case to upper case).  This could happen transparently
      when a bundle is synched to disk using one set of software and
      then read from disk and forwarded by a second set of software.
      Because there are no general rules for canonicalizing URIs (or
      IRIs), this problem may be an unavoidable source of integrity
      failures.

   o  All SDNV fields here are canonicalized as eight-byte unpacked
      values in network byte order.  Length fields are canonicalized as
      four-byte values in network byte order.  Encoding does not need
      optimization since the values are never sent over the network.

      If a bundle is fragmented before the PIB is applied, then the PIB
      applies to a fragment and not the entire bundle.  However, the
      protected fragment could be subsequently further fragmented, which
      would leave the verifier unable to know which bytes were protected



<span class="grey">Symington, et al.             Experimental                     [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


      by the PIB.  Even in the absence of fragmentation, the same
      situation applies if the ciphersuite is defined to allow
      protection of less than the entire, original bundle payload.

      For this reason, PIB ciphersuites that support applying a PIB to
      less than the complete, original bundle payload MUST specify, as
      part of the ciphersuite-parameters, which bytes of the bundle
      payload are protected.  When verification occurs, only the
      specified range of the payload bytes are input to PIB
      verification.  It is valid for a ciphersuite to be specified so as
      to only apply to entire bundles and not to fragments.  A
      ciphersuite MAY be specified to apply to only a portion of the
      payload, regardless of whether the payload is a fragment or the
      complete, original bundle payload.

      The same fragmentation issue applies equally to PCB ciphersuites.
      Ciphersuites that support applying confidentiality to fragments
      MUST specify, as part of the ciphersuite-parameters, which bytes
      of the bundle payload are protected.  When decrypting a fragment,
      only the specified bytes are processed.  It is also valid for a
      confidentiality ciphersuite to be specified so as to only apply to
      entire bundles and not to fragments.

   This definition of mutable canonicalization assumes that endpoint IDs
   themselves are immutable and is unsuitable for use in environments
   where that assumption might be violated.

   The canonicalization applies to a specific bundle and not a specific
   payload.  If a bundle is forwarded in some way, the recipient is not
   able to verify the original integrity signature since the source EID
   will be different, and possibly other fields.

   The solution for either of these issues is to define and use a PIB
   ciphersuite having an alternate version of mutable canonicalization
   any fields from the primary block.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Endpoint ID Confidentiality</span>

   Every bundle MUST contain a primary block that contains the source
   and destination endpoint IDs, and possibly other EIDs (in the
   dictionary field), and that cannot be encrypted.  If endpoint ID
   confidentiality is required, then bundle-in-bundle encapsulation can
   solve this problem in some instances.

   Similarly, confidentiality requirements MAY also apply to other parts
   of the primary block (e.g., the current-custodian), and that is
   supported in the same manner.




<span class="grey">Symington, et al.             Experimental                     [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>.  Bundles Received from Other Nodes</span>

   Nodes implementing this specification SHALL consult their security
   policy to determine whether or not a received bundle is required by
   policy to include a BAB.  If the bundle has no BAB, and one is not
   required, then BAB processing on the received bundle is complete, and
   the bundle is ready to be further processed for PIB/PCB/ESB handling
   or delivery or forwarding.

   If the bundle is required to have a BAB but does not, then the bundle
   MUST be discarded and processed no further.  If the bundle is
   required to have a BAB but all of its BABs identify a node other than
   the receiving node as the BAB security-destination, then the bundle
   MUST be discarded and processed no further.

   If the bundle is required to have a BAB, and has one or more BABs
   that identify the receiving node as the BAB security-destination, or
   for which there is no security-destination, then the value in the
   security-result field(s) of the BAB(s) MUST be verified according to
   the ciphersuite specification.  If, for all such BABs in the bundle,
   either the BAB security source cannot be determined or the security-
   result value check fails, the bundle has failed to authenticate, and
   the bundle MUST be discarded and processed no further.  If any of the
   BABs present verify, or if a BAB is not required, the bundle is ready
   for further processing as determined by extension blocks and/or
   policy.

   BABs received in a bundle MUST be stripped before the bundle is
   forwarded.  New BABs MAY be added as required by policy.  This MAY
   require correcting the "last block" field of the to-be-forwarded
   bundle.

   Further processing of the bundle MUST take place in the order
   indicated by the various blocks from the primary block to the payload
   block, except as defined by an applicable specification.

   If the bundle has a PCB and the receiving node is the PCB-destination
   for the bundle (either because the node is listed as the bundle's
   PCB-destination or because the node is listed as the bundle-
   destination and there is no PCB-dest), the node MUST decrypt the
   relevant parts of the bundle in accordance with the ciphersuite
   specification.  The PCB SHALL be deleted.  If the relevant parts of
   the bundle cannot be decrypted (i.e., the decryption key cannot be
   deduced or decryption fails), then the bundle MUST be discarded and
   processed no further; in this case, a bundle deletion status report
   (see the Bundle Protocol Specification [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>]) indicating the
   decryption failure MAY be generated.  If the PCB security-result




<span class="grey">Symington, et al.             Experimental                     [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   included the ciphertext of a block other than the payload block, the
   recovered plaintext block MUST be placed in the bundle at the
   location from which the PCB was deleted.

   If the bundle has one or more PIBs for which the receiving node is
   the bundle's PIB-destination (either because the node is listed in
   the bundle's PIB-destination or because the node is listed as the
   bundle-destination and there is no PIB-dest), the node MUST verify
   the value in the PIB security-result field(s) in accordance with the
   ciphersuite specification.  If all the checks fail, the bundle has
   failed to authenticate and the bundle SHALL be processed according to
   the security policy.  A bundle status report indicating the failure
   MAY be generated.  Otherwise, if the PIB verifies, the bundle is
   ready to be processed for either delivery or forwarding.  Before
   forwarding the bundle, the node SHOULD remove the PIB from the
   bundle, subject to the requirements of <a href="#section-3.2">Section 3.2</a>, unless it is
   likely that some downstream node will also be able to verify the PIB.

   If the bundle has a PIB and the receiving node is not the bundle's
   PIB-dest, the receiving node MAY attempt to verify the value in the
   security-result field.  If it is able to check and the check fails,
   the node SHALL discard the bundle and it MAY send a bundle status
   report indicating the failure.

   If the bundle has an ESB and the receiving node is the ESB-
   destination for the bundle (either because the node is listed as the
   bundle's ESB-destination or because the node is listed as the bundle-
   destination and there is no ESB-destination), the node MUST decrypt
   and/or decapsulate the encapsulated block in accordance with the
   ciphersuite specification.  The decapsulated block replaces the ESB
   in the bundle block sequence, and the ESB is thereby deleted.  If the
   content cannot be decrypted (i.e., the decryption key cannot be
   deduced or decryption fails), then the bundle MAY be discarded and
   processed no further unless the security policy specifies otherwise.
   In this case, a bundle deletion status report (see the Bundle
   Protocol Specification [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>]) indicating the decryption failure MAY
   be generated.

<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>.  The At-Most-Once-Delivery Option</span>

   An application MAY request (in an implementation-specific manner)
   that a node be registered as a member of an endpoint and that
   received bundles destined for that endpoint be delivered to that
   application.

   An option for use in such cases is known as "at-most-once-delivery".
   If this option is chosen, the application indicates that it wants the
   node to check for duplicate bundles, discard duplicates, and deliver



<span class="grey">Symington, et al.             Experimental                     [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   at most one copy of each received bundle to the application.  If this
   option is not chosen, the application indicates that it wants the
   node to deliver all received bundle copies to the application.  If
   this option is chosen, the node SHALL deliver at most one copy of
   each received bundle to the application.  If the option is not
   chosen, the node SHOULD, subject to policy, deliver all bundles.

   To enforce this, the node MUST look at the source/timestamp pair
   value of each complete (reassembled, if necessary) bundle received
   and determine if this pair, which uniquely identifies a bundle, has
   been previously received.  If it has, then the bundle is a duplicate.
   If it has not, then the bundle is not a duplicate.  The source/
   timestamp pair SHALL be added to the list of pair values already
   received by that node.

   Each node implementation MAY decide how long to maintain a table of
   pair value state.

<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>.  Bundle Fragmentation and Reassembly</span>

   If it is necessary for a node to fragment a bundle and security
   services have been applied to that bundle, the fragmentation rules
   described in [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>] MUST be followed.  As defined there and repeated
   here for completeness, only the payload MAY be fragmented; security
   blocks, like all extension blocks, can never be fragmented.  In
   addition, the following security-specific processing is REQUIRED:

   The security policy requirements for a bundle MUST be applied
   individually to all the bundles resulting from a fragmentation event.

   If the original bundle contained a PIB, then each of the PIB
   instances MUST be included in some fragment.

   If the original bundle contained one or more PCBs, then any PCB
   instances containing a key-information item MUST have the "replicate
   in every fragment" flag set, and thereby be replicated in every
   fragment.  This is to ensure that the canonical block-sequence can be
   recovered during reassembly.

   If the original bundle contained one or more correlated PCBs not
   containing a key-information item, then each of these MUST be
   included in some fragment, but SHOULD NOT be sent more than once.
   They MUST be placed in a fragment in accordance with the
   fragmentation rules described in [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>].







<span class="grey">Symington, et al.             Experimental                     [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   Note: various fragments MAY have additional security blocks added at
   this or later stages, and it is possible that correlators will
   collide.  In order to facilitate uniqueness, ciphersuites SHOULD
   include the fragment-offset of the fragment as a high-order component
   of the correlator.

<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a>.  Reactive Fragmentation</span>

   When a partial bundle has been received, the receiving node SHALL
   consult its security policy to determine if it MAY fragment the
   bundle, converting the received portion into a bundle fragment for
   further forwarding.  Whether or not reactive fragmentation is
   permitted SHALL depend on the security policy and the ciphersuite
   used to calculate the BAB authentication information, if required.
   (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC (Hashed Message
   Authentication Code) ciphersuite defined in <a href="#section-4.1">Section 4.1</a>, do not
   accommodate reactive fragmentation because the security-result in the
   BAB requires that the entire bundle be signed.  It is conceivable,
   however, that a BAB ciphersuite could be defined such that multiple
   security-results are calculated, each on a different segment of a
   bundle, and that these security-results could be interspersed between
   bundle payload segments such that reactive fragmentation could be
   accommodated.)

   If the bundle is reactively fragmented by the intermediate receiver
   and the BAB-ciphersuite is of an appropriate type (e.g., with
   multiple security-results embedded in the payload), the bundle MUST
   be fragmented immediately after the last security-result value in the
   partial payload that is received.  Any data received after the last
   security-result value MUST be dropped.

   If a partial bundle is received at the intermediate receiver and is
   reactively fragmented and forwarded, only the part of the bundle that
   was not received MUST be retransmitted, though more of the bundle MAY
   be retransmitted.  Before retransmitting a portion of the bundle, it
   SHALL be changed into a fragment and, if the original bundle included
   a BAB, the fragmented bundle MUST also, and its BAB SHALL be
   recalculated.

   This specification does not define any ciphersuite that can handle
   this reactive fragmentation case.

   An interesting possibility is a ciphersuite definition such that the
   transmission of a follow-up fragment would be accompanied by the
   signature for the payload up to the restart point.






<span class="grey">Symington, et al.             Experimental                     [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


<span class="h3"><a class="selflink" id="section-3.10" href="#section-3.10">3.10</a>.  Attack Model</span>

   An evaluation of resilience to cryptographic attack necessarily
   depends upon the algorithms chosen for bulk data protection and for
   key transport.  The mandatory ciphersuites described in the following
   section use AES, RSA, and SHA algorithms in ways that are believed to
   be reasonably secure against ciphertext-only, chosen-ciphertext,
   known-plaintext, and chosen-plaintext attacks.

   The design has carefully preserved the resilience of the algorithms
   against attack.  For example, if a message is encrypted, then any
   message integrity signature is also encrypted so that guesses cannot
   be confirmed.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Mandatory Ciphersuites</span>

   This section defines the mandatory ciphersuites for this
   specification.  There is currently one mandatory ciphersuite for use
   with each of the security block types BAB, PIB, PCB, and ESB.  The
   BAB ciphersuite is based on shared secrets using HMAC.  The PIB
   ciphersuite is based on digital signatures using RSA with SHA-256.
   The PCB and ESB ciphersuites are based on using RSA for key transport
   and AES for bulk encryption.

   In all uses of CMS eContent in this specification, the relevant
   eContentType to be used is id-data as specified in [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>].

   The ciphersuites use the mechanisms defined in Cryptographic Message
   Syntax (CMS) [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>] for packaging the keys, signatures, etc., for
   transport in the appropriate security block.  The data in the CMS
   object is not the bundle data, as would be the typical usage for CMS.
   Rather, the "message data" packaged by CMS is the ephemeral key,
   message digest, etc., used in the core code of the ciphersuite.

   In all cases where we use CMS, implementations SHOULD NOT include
   additional attributes whether signed or unsigned, authenticated or
   unauthenticated.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  BAB-HMAC</span>

   The BAB-HMAC ciphersuite has ciphersuite ID value 0x001.

   BAB-HMAC uses the strict canonicalization algorithm in <a href="#section-3.4.1">Section 3.4.1</a>.

   Strict canonicalization supports digesting of a fragment-bundle.  It
   does not permit the digesting of only a subset of the payload, but
   only the complete contents of the payload of the current bundle,




<span class="grey">Symington, et al.             Experimental                     [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   which might be a fragment.  The fragment-range item for security-
   parameters is not used to indicate a fragment, as this information is
   digested within the primary block.

   The variant of HMAC to be used is HMAC-SHA1 as defined in [<a href="./rfc2104" title="&quot;HMAC: Keyed- Hashing for Message Authentication&quot;">RFC2104</a>].

   This ciphersuite requires the use of two related instances of the
   BAB.  It involves placing the first BAB instance (as defined in
   <a href="#section-2.2">Section 2.2</a>) just after the primary block.  The second (correlated)
   instance of the BAB MUST be placed after all other blocks (except
   possibly other BAB blocks) in the bundle.

   This means that, normally, the BAB will be the second and last blocks
   of the bundle.  If a forwarder wishes to apply more than one
   correlated BAB pair, then this can be done.  There is no requirement
   that each application "wrap" the others, but the forwarder MUST
   insert all the "up front" BABs, and their "at back" "partners"
   (without any security-result), before canonicalizing.

   Inserting more than one correlated BAB pair would be useful if the
   bundle could be routed to more than one potential "next hop" or if
   both an old and a new key were valid at sending time, with no
   certainty about the situation that will obtain at reception time.

   The security-result is the output of the HMAC-SHA1 calculation with
   the input being the result of running the entire bundle through the
   strict canonicalization algorithm.  Both required BAB instances MUST
   be included in the bundle before canonicalization.

   Security-parameters are OPTIONAL with this scheme, but if used, then
   the only field that can be present is key-information (see
   <a href="#section-2.6">Section 2.6</a>).

   In the absence of key-information, the receiver is expected to be
   able to find the correct key based on the sending identity.  The
   sending identity MAY be known from the security-source field or the
   content of a previous-hop block in the bundle.  It MAY also be
   determined using implementation-specific means such as the
   convergence layer.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  PIB-RSA-SHA256</span>

   The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02.

   PIB-RSA-SHA256 uses the mutable canonicalization algorithm in
   <a href="#section-3.4.2">Section 3.4.2</a>, with the security-result data field for only the
   "current" block being excluded from the canonical form.  The




<span class="grey">Symington, et al.             Experimental                     [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   resulting canonical form of the bundle is the input to the signing
   process.  This ciphersuite requires the use of a single instance of
   the PIB.

   Because the signature field in SignedData SignatureValue is a
   security-result field, the entire key-information item MUST be placed
   in the block's security-result field, rather than security-
   parameters.

   If the bundle being signed has been fragmented before signing, then
   we have to specify which bytes were signed in case the signed bundle
   is subsequently fragmented for a second time.  If the bundle is a
   fragment, then the ciphersuite-parameters MUST include a fragment-
   range field, as described in <a href="#section-2.6">Section 2.6</a>, specifying the offset and
   length of the signed fragment.  If the entire bundle is signed, then
   these numbers MUST be omitted.

   Implementations MUST support the use of the "SignedData" type as
   defined in <a href="./rfc5652#section-5.1">[RFC5652], Section&nbsp;5.1</a>, with SignerInfo type
   SignerIdentifier containing the issuer and serial number of a
   suitable certificate.  The data to be signed is the output of the
   SHA256 mutable canonicalization process.

   RSA is used with SHA256 as specified for the id-sha256 signature
   scheme in <a href="./rfc4055#section-5">[RFC4055], Section&nbsp;5</a>.  The output of the signing process is
   the SignatureValue field for the PIB.

   "Commensurate strength" cryptography is generally held to be a good
   idea.  A combination of RSA with SHA-256 is reckoned to require a
   3076-bit RSA key according to this logic.  Few implementations will
   choose this length by default (and probably some just will not
   support such long keys).  Since this is an experimental protocol, we
   expect that 1024- or 2048-bit RSA keys will be used in many cases,
   and that this will be fine since we also expect that the hash
   function "issues" will be resolved before any standard would be
   derived from this protocol.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  PCB-RSA-AES128-PAYLOAD-PIB-PCB</span>

   The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID
   value 0x003.

   This scheme encrypts PIBs, PCBs, and the payload.  The key size for
   this ciphersuite is 128 bits.

   Encryption is done using the AES algorithm in Galois/Counter Mode
   (GCM) as described in [<a href="./rfc5084" title="&quot;Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)&quot;">RFC5084</a>].  Note: parts of the following
   description are borrowed from [<a href="./rfc4106" title="&quot;The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)&quot;">RFC4106</a>].



<span class="grey">Symington, et al.             Experimental                     [Page 44]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   The choice of GCM avoids expansion of the payload, which causes
   problems with fragmentation/reassembly and custody transfer.  GCM
   also includes authentication, essential in preventing attacks that
   can alter the decrypted plaintext or even recover the encryption key.

   GCM is a block cipher mode of operation providing both
   confidentiality and data integrity.  The GCM encryption operation has
   four inputs: a secret key, an initialization vector (IV), a
   plaintext, and an input for additional authenticated data (AAD),
   which is not used here.  It has two outputs, a ciphertext whose
   length is identical to the plaintext, and an authentication tag, also
   known as the integrity check value (ICV).

   For consistency with the description in [<a href="./rfc5084" title="&quot;Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)&quot;">RFC5084</a>], we refer to the
   GCM IV as a nonce.  The same key and nonce combination MUST NOT be
   used more than once.  The nonce has the following layout:

   +----------------+----------------+----------------+----------------+
   |                               salt                                |
   +----------------+----------------+----------------+----------------+
   |                                                                   |
   |                      initialization vector                        |
   |                                                                   |
   +----------------+----------------+----------------+----------------+

         Figure 6: Nonce Format for PCB-RSA-AES128-PAYLOAD-PIB-PCB

   The salt field is a four-octet value, usually chosen at random.  It
   MUST be the same for all PCBs that have the same correlator value.
   The salt need not be kept secret.

   The initialization vector (IV) is an eight-octet value, usually
   chosen at random.  It MUST be different for all PCBs that have the
   same correlator value.  The value need not be kept secret.

   The key (bundle encryption key, BEK) is a 16-octet (128 bits) value,
   usually chosen at random.  The value MUST be kept secret, as
   described below.

   The integrity check value is a 16-octet value used to verify that the
   protected data has not been altered.  The value need not be kept
   secret.

   This ciphersuite requires the use of a single PCB instance to deal
   with payload confidentiality.  If the bundle already contains PIBs or
   PCBs, then the ciphersuite will create additional correlated blocks
   to protect these PIBs and PCBs.  These "additional" blocks replace
   the original blocks on a one-to-one basis, so the number of blocks



<span class="grey">Symington, et al.             Experimental                     [Page 45]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-46" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   remains unchanged.  All of these related blocks MUST have the same
   correlator value.  The term "first PCB" in this section refers to the
   single PCB if there is only one or, if there are several, then to the
   one containing the key-information.  This MUST be the first of the
   set.

   First PCB - the first PCB MAY contain a correlator value, and MAY
   specify security-source and/or security-destination in the EID-list.
   If not specified, the bundle-source and bundle-destination,
   respectively, are used for these values, as with other ciphersuites.
   The block MUST contain security-parameters and security-result
   fields.  Each field MAY contain several items formatted as described
   in <a href="#section-2.6">Section 2.6</a>.

   Security-parameters

      key-information

      salt

      IV (this instance applies only to payload)

      fragment offset and length, if bundle is a fragment

   Security-result

      ICV

   Subsequent PCBs MUST contain a correlator value to link them to the
   first PCB.  Security-source and security-destination are implied from
   the first PCB; however, see the discussion in <a href="#section-2.4">Section 2.4</a> concerning
   EID-list entries.  They MUST contain security-parameters and
   security-result fields as follows:

   Security-parameters

      IV for this specific block

   Security-result

      encapsulated block

   The security-parameters and security-result fields in the subsequent
   PCBs MUST NOT contain any items other than these two.  Items such as
   key and salt are supplied in the first PCB and MUST NOT be repeated.






<span class="grey">Symington, et al.             Experimental                     [Page 46]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-47" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   Implementations MUST support use of "enveloped-data" type as defined
   in <a href="./rfc5652#section-6">[RFC5652], Section&nbsp;6</a>, with RecipientInfo type
   KeyTransRecipientInfo containing the issuer and serial number of a
   suitable certificate.  They MAY support additional RecipientInfo
   types.  The "encryptedContent" field in EncryptedContentInfo contains
   the encrypted BEK that protects the payload and certain security
   blocks of the bundle.

   The Integrity Check Value from the AES-GCM encryption of the payload
   is placed in the security-result field of the first PCB.

   If the bundle being encrypted is a fragment-bundle, we have to
   specify which bytes are encrypted in case the bundle is subsequently
   fragmented again.  If the bundle is a fragment, the ciphersuite-
   parameters MUST include a fragment-range field, as described in
   <a href="#section-2.6">Section 2.6</a>, specifying the offset and length of the encrypted
   fragment.  Note that this is not the same pair of fields that appear
   in the primary block as "offset and length".  The "length" in this
   case is the length of the fragment, not the original length.  If the
   bundle is not a fragment, then this field MUST be omitted.

   The confidentiality processing for payload and other blocks is
   different, mainly because the payload might be fragmented later at
   some other node.

   For the payload, only the bytes of the bundle payload field are
   affected, being replaced by ciphertext.  The salt, IV, and key values
   specified in the first PCB are used to encrypt the payload, and the
   resultant authentication tag (ICV) is placed in an ICV item in the
   security-result field of that first PCB.  The other bytes of the
   payload block, such as type, flags, and length, are not modified.

   For each PIB or PCB to be protected, the entire original block is
   encapsulated in a "replacing" PCB.  This replacing PCB is placed in
   the outgoing bundle in the same position as the original block, PIB
   or PCB.  As mentioned above, this is one-to-one replacement, and
   there is no consolidation of blocks or mixing of data in any way.

   The encryption process uses AES-GCM with the salt and key values from
   the first PCB, and an IV unique to this PCB.  The process creates
   ciphertext for the entire original block and an authentication tag
   for validation at the security-destination.  For this encapsulation
   process, unlike the processing of the bundle payload, the
   authentication tag is appended to the ciphertext for the block, and
   the combination is stored into the encapsulated block item in the
   security-result.





<span class="grey">Symington, et al.             Experimental                     [Page 47]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-48" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   The replacing block, of course, also has the same correlator value as
   the first PCB with which it is associated.  It also contains the
   block-specific IV in security-parameters, and the combination of
   original-block-ciphertext and authentication tag, stored as an
   encapsulated block item in the security-result.

   If the payload was fragmented after encryption, then all those
   fragments MUST be present and reassembled before decryption.  This
   process might be repeated several times at different destinations if
   multiple fragmentation actions have occurred.

   The size of the GCM counter field limits the payload size to 2^39 -
   256 bytes, about half a terabyte.  A future revision of this
   specification will address the issue of handling payloads in excess
   of this size.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  ESB-RSA-AES128-EXT</span>

   The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004.

   This scheme encrypts non-payload-related blocks.  It MUST NOT be used
   to encrypt PIBs, PCBs, or primary or payload blocks.  The key size
   for this ciphersuite is 128 bits.

   Encryption is done using the AES algorithm in Galois/Counter Mode
   (GCM) as described in [<a href="./rfc5084" title="&quot;Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)&quot;">RFC5084</a>].  Note: parts of the following
   description are borrowed from [<a href="./rfc4106" title="&quot;The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)&quot;">RFC4106</a>].

   GCM is a block cipher mode of operation providing both
   confidentiality and data origin authentication.  The GCM
   authenticated encryption operation has four inputs: a secret key, an
   initialization vector (IV), a plaintext, and an input for additional
   authenticated data (AAD), which is not used here.  It has two
   outputs, a ciphertext whose length is identical to the plaintext, and
   an authentication tag, also known as the Integrity Check Value (ICV).

   For consistency with the description in [<a href="./rfc5084" title="&quot;Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)&quot;">RFC5084</a>], we refer to the
   GCM IV as a nonce.  The same key and nonce combination MUST NOT be
   used more than once.  The nonce has the following layout:












<span class="grey">Symington, et al.             Experimental                     [Page 48]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-49" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   +----------------+----------------+---------------------------------+
   |                               salt                                |
   +----------------+----------------+---------------------------------+
   |                                                                   |
   |                      initialization vector                        |
   |                                                                   |
   +----------------+----------------+---------------------------------+

               Figure 7: Nonce Format for ESB-RSA-AES128-EXT

   The salt field is a four-octet value, usually chosen at random.  It
   MUST be the same for all ESBs that have the same correlator value.
   The salt need not be kept secret.

   The initialization vector (IV) is an eight-octet value, usually
   chosen at random.  It MUST be different for all ESBs that have the
   same correlator value.  The value need not be kept secret.

   The data encryption key is a 16-octet (128 bits) value, usually
   chosen at random.  The value MUST be kept secret, as described below.

   The integrity check value is a 16-octet value used to verify that the
   protected data has not been altered.  The value need not be kept
   secret.

   This ciphersuite replaces each BP extension block to be protected
   with a "replacing" ESB, and each can be individually specified.

   If a number of related BP extension blocks are to be protected, they
   can be grouped as a correlated set and protected using a single key.
   These blocks replace the original blocks on a one-to-one basis, so
   the number of blocks remains unchanged.  All these related blocks
   MUST have the same correlator value.  The term "first ESB" in this
   section refers to the single ESB if there is only one or, if there
   are several, then to the one containing the key or key-identifier.
   This MUST be the first of the set.  If the blocks are individually
   specified, then there is no correlated set and each block is its own
   "first ESB".

   First ESB - the first ESB MAY contain a correlator value, and MAY
   specify security-source and/or security-destination in the EID-list.
   If not specified, the bundle-source and bundle-destination,
   respectively, are used for these values, as with other ciphersuites.
   The block MUST contain security-parameters and security-result
   fields.  Each field MAY contain several items formatted as described
   in <a href="#section-2.6">Section 2.6</a>.





<span class="grey">Symington, et al.             Experimental                     [Page 49]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-50" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   Security-parameters

      key-information

      salt

      IV for this specific block

      block type of encapsulated block (OPTIONAL)

   Security-result

      encapsulated block

   Subsequent ESBs MUST contain a correlator value to link them to the
   first ESB.  Security-source and security-destination are implied from
   the first ESB; however, see the discussion in <a href="#section-2.4">Section 2.4</a> concerning
   EID-list entries.  Subsequent ESBs MUST contain security-parameters
   and security-result fields as follows:

   Security-parameters

      IV for this specific block

      block type of encapsulated block (OPTIONAL)

   Security-result

      encapsulated block

   The security-parameters and security-result fields in the subsequent
   ESBs MUST NOT contain any items other than those listed.  Items such
   as key-information and salt are supplied in the first ESB and MUST
   NOT be repeated.

   Implementations MUST support the use of "enveloped-data" type as
   defined in <a href="./rfc5652#section-6">[RFC5652], Section&nbsp;6</a>, with RecipientInfo type
   KeyTransRecipientInfo containing the issuer and serial number of a
   suitable certificate.  They MAY support additional RecipientInfo
   types.  The "encryptedContent" field in EncryptedContentInfo contains
   the encrypted BEK used to encrypt the content of the block being
   protected.

   For each block to be protected, the entire original block is
   encapsulated in a "replacing" ESB.  This replacing ESB is placed in
   the outgoing bundle in the same position as the original block.  As
   mentioned above, this is one-to-one replacement, and there is no
   consolidation of blocks or mixing of data in any way.



<span class="grey">Symington, et al.             Experimental                     [Page 50]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-51" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   The encryption process uses AES-GCM with the salt and key values from
   the first ESB and an IV unique to this ESB.  The process creates
   ciphertext for the entire original block, and an authentication tag
   for validation at the security-destination.  The authentication tag
   is appended to the ciphertext for the block and the combination is
   stored into the encapsulated block item in security-result.

   The replacing block, of course, also has the same correlator value as
   the first ESB with which it is associated.  It also contains the
   block-specific IV in security-parameters, and the combination of
   original-block-ciphertext and authentication tag, stored as an
   encapsulated block item in security-result.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Key Management</span>

   Key management in delay-tolerant networks is recognized as a
   difficult topic and is one that this specification does not attempt
   to solve.  However, solely in order to support implementation and
   testing, implementations SHOULD support:

   o  The use of well-known RSA public keys for all ciphersuites.

   o  Long-term pre-shared-symmetric keys for the BAB-HMAC ciphersuite.

   Since endpoint IDs are URIs and URIs can be placed in X.509 [<a href="./rfc5280" title="&quot;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC5280</a>]
   public key certificates (in the subjectAltName extension),
   implementations SHOULD support this way of distributing public keys.
   <a href="./rfc5280">RFC 5280</a> does not insist that implementations include revocation
   checking.  In the context of a DTN, it is reasonably likely that some
   nodes would not be able to use revocation checking services (either
   Certificate Revocation Lists (CRLs) or the Online Certificate Status
   Protocol (OCSP)) and deployments SHOULD take this into account when
   planning any public key infrastructure to support this specification.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Default Security Policy</span>

   Every node serves as a Policy Enforcement Point insofar as it
   enforces some policy that controls the forwarding and delivery of
   bundles via one or more convergence layer protocol implementation.
   Consequently, every node SHALL have and operate according to its own
   configurable security policy, whether the policy be explicit or
   default.  The policy SHALL specify:

      Under what conditions received bundles SHALL be forwarded.

      Under what conditions received bundles SHALL be required to
      include valid BABs.




<span class="grey">Symington, et al.             Experimental                     [Page 51]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-52" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


      Under what conditions the authentication information provided in a
      bundle's BAB SHALL be deemed adequate to authenticate the bundle.

      Under what conditions received bundles SHALL be required to have
      valid PIBs and/or PCBs.

      Under what conditions the authentication information provided in a
      bundle's PIB SHALL be deemed adequate to authenticate the bundle.

      Under what conditions a BAB SHALL be added to a received bundle
      before that bundle is forwarded.

      Under what conditions a PIB SHALL be added to a received bundle
      before that bundle is forwarded.

      Under what conditions a PCB SHALL be added to a received bundle
      before that bundle is forwarded.

      Under what conditions an ESB SHALL be applied to one or more
      blocks in a received bundle before that bundle is forwarded.

      The actions that SHALL be taken in the event that a received
      bundle does not meet the receiving node's security policy
      criteria.

   This specification does not address how security policies get
   distributed to nodes.  It only REQUIRES that nodes have and enforce
   security policies.

   If no security policy is specified at a given node, or if a security
   policy is only partially specified, that node's default policy
   regarding unspecified criteria SHALL consist of the following:

      Bundles that are not well-formed do not meet the security policy
      criteria.

      The mandatory ciphersuites MUST be used.

      All bundles received MUST have a BAB that MUST be verified to
      contain a valid security-result.  If the bundle does not have a
      BAB, then the bundle MUST be discarded and processed no further; a
      bundle status report indicating the authentication failure MAY be
      generated.

      No received bundles SHALL be required to have a PIB; if a received
      bundle does have a PIB, however, the PIB can be ignored unless the
      receiving node is the PIB-destination, in which case the PIB MUST
      be verified.



<span class="grey">Symington, et al.             Experimental                     [Page 52]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-53" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


      No received bundles SHALL be required to have a PCB; if a received
      bundle does have a PCB, however, the PCB can be ignored unless the
      receiving node is the PCB-destination, in which case the PCB MUST
      be processed.  If processing a PCB yields a PIB, that PIB SHALL be
      processed by the node according to the node's security policy.

      A PIB SHALL NOT be added to a bundle before sourcing or forwarding
      it.

      A PCB SHALL NOT be added to a bundle before sourcing or forwarding
      it.

      A BAB MUST always be added to a bundle before that bundle is
      forwarded.

      If a destination node receives a bundle that has a PIB-destination
      but the value in that PIB-destination is not the EID of the
      destination node, the bundle SHALL be delivered at that
      destination node.

      If a destination node receives a bundle that has an ESB-
      destination but the value in that ESB-destination is not the EID
      of the destination node, the bundle SHALL be delivered at that
      destination node.

      If a received bundle does not satisfy the node's security policy
      for any reason, then the bundle MUST be discarded and processed no
      further; in this case, a bundle deletion status report (see the
      Bundle Protocol Specification [<a href="#ref-DTNBP" title="&quot;Bundle Protocol Specification&quot;">DTNBP</a>]) indicating the failure MAY
      be generated.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   The Bundle Security Protocol builds upon much work of others, in
   particular, "Cryptographic Message Syntax (CMS)" [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>] and
   "Internet X.509 Public Key Infrastructure Certificate and Certificate
   Revocation List (CRL) Profile" [<a href="./rfc5280" title="&quot;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;">RFC5280</a>].  The security
   considerations in these two documents apply here as well.

   Several documents specifically consider the use of Galois/Counter
   Mode (GCM) and of AES and are important to consider when building
   ciphersuites.  These are "The Use of Galois/Counter Mode (GCM) in
   IPsec Encapsulating Security Payload (ESP)" [<a href="./rfc4106" title="&quot;The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)&quot;">RFC4106</a>] and "Using AES-
   CCM and AES-GCM Authenticated Encryption in the Cryptographic Message
   Syntax (CMS)" [<a href="./rfc5084" title="&quot;Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)&quot;">RFC5084</a>].  Although the BSP is not identical, many of
   the security issues considered in these documents also apply here.





<span class="grey">Symington, et al.             Experimental                     [Page 53]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-54" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   Certain applications of DTN need to both sign and encrypt a message,
   and there are security issues to consider with this.

   If the intent is to provide an assurance that a message did, in fact,
   come from a specific source and has not been changed, then it should
   be signed first and then encrypted.  A signature on an encrypted
   message does not establish any relationship between the signer and
   the original plaintext message.

   On the other hand, if the intent is to reduce the threat of denial-
   of-service attacks, then signing the encrypted message is
   appropriate.  A message that fails the signature check will not be
   processed through the computationally intensive decryption pass.  A
   more extensive discussion of these points is in S/MIME 3.2 Message
   Specification [<a href="./rfc5751" title="&quot;Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification&quot;">RFC5751</a>], especially in <a href="#section-3.6">Section 3.6</a>.

   Additional details relating to these combinations can be found in
   <a href="#section-2.8">Section 2.8</a> where it is RECOMMENDED that the encrypt-then-sign
   combination is usually appropriate for usage in a DTN.

   In a DTN, encrypt-then-sign potentially allows intermediate nodes to
   verify a signature (over the ciphertext) and thereby apply policy to
   manage possibly scarce storage or other resources at intermediate
   nodes in the path the bundle takes from source to destination EID.

   An encrypt-then-sign scheme does not further expose identity in most
   cases since the BP mandates that the source EID (which is commonly
   expected to be the security-source) is already exposed in the primary
   block of the bundle.  Should exposure of either the source EID or the
   signerInfo be considered an interesting vulnerability, then some form
   of bundle-in-bundle encapsulation would be required as a mitigation.

   If a BAB ciphersuite uses digital signatures but doesn't include the
   security-destination (which for a BAB is the next host), then this
   allows the bundle to be sent to some node other than the intended
   adjacent node.  Because the BAB will still authenticate, the
   receiving node might erroneously accept and forward the bundle.  When
   asymmetric BAB ciphersuites are used, the security-destination field
   SHOULD therefore be included in the BAB.

   If a bundle's PIB-destination is not the same as its destination,
   then some node other than the destination (the node identified as the
   PIB-destination) is expected to validate the PIB security-result
   while the bundle is en route.  However, if for some reason the PIB is
   not validated, there is no way for the destination to become aware of
   this.  Typically, a PIB-destination will remove the PIB from the
   bundle after verifying the PIB and before forwarding it.  However, if
   there is a possibility that the PIB will also be verified at a



<span class="grey">Symington, et al.             Experimental                     [Page 54]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-55" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   downstream node, the PIB-destination will leave the PIB in the
   bundle.  Therefore, if a destination receives a bundle with a PIB
   that has a PIB-destination (which isn't the destination), this might,
   but does not necessarily, indicate a possible problem.

   If a bundle is fragmented after being forwarded by its PIB-source but
   before being received by its PIB-destination, the payload in the
   bundle MUST be reassembled before validating the PIB security-result
   in order for the security-result to validate correctly.  Therefore,
   if the PIB-destination is not capable of performing payload
   reassembly, its utility as a PIB-destination will be limited to
   validating only those bundles that have not been fragmented since
   being forwarded from the PIB-source.  Similarly, if a bundle is
   fragmented after being forwarded by its PIB-source but before being
   received by its PIB-destination, all fragments MUST be received at
   that PIB-destination in order for the bundle payload to be able to be
   reassembled.  If not all fragments are received at the PIB-
   destination node, the bundle will not be able to be authenticated,
   and will therefore never be forwarded by this PIB-destination node.

   Specification of a security-destination other than the bundle-
   destination creates a routing requirement that the bundle somehow be
   directed to the security-destination node on its way to the final
   destination.  This requirement is presently private to the
   ciphersuite, since routing nodes are not required to implement
   security processing.

   If a security target were to generate reports in the event that some
   security validation step fails, then that might leak information
   about the internal structure or policies of the DTN containing the
   security target.  This is sometimes considered bad security practice,
   so it SHOULD only be done with care.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Conformance</span>

   As indicated above, this document describes both BSP and
   ciphersuites.  A conformant implementation MUST implement both BSP
   support and the four ciphersuites described in <a href="#section-4">Section 4</a>.  It MAY
   also support other ciphersuites.

   Implementations that support BSP but not all four mandatory
   ciphersuites MUST claim only "restricted compliance" with this
   specification, even if they provide other ciphersuites.

   All implementations are strongly RECOMMENDED to provide at least a
   BAB ciphersuite.  A relay node, for example, might not deal with end-
   to-end confidentiality and data integrity, but it SHOULD exclude
   unauthorized traffic and perform hop-by-hop bundle verification.



<span class="grey">Symington, et al.             Experimental                     [Page 55]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-56" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  IANA Considerations</span>

   This protocol has fields that have been registered by IANA.

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Bundle Block Types</span>

   This specification allocates four codepoints from the existing
   "Bundle Block Types" registry defined in [<a href="./rfc6255" title="&quot;Delay-Tolerant Networking (DTN) Bundle Protocol IANA Registries&quot;">RFC6255</a>].

      Additional Entries for the Bundle Block-Type Codes Registry:
      +-------+--------------------------------------+----------------+
      | Value | Description                          | Reference      |
      +-------+--------------------------------------+----------------+
      |     2 | Bundle Authentication Block          | This document  |
      |     3 | Payload Integrity Block              | This document  |
      |     4 | Payload Confidentiality Block        | This document  |
      |     9 | Extension Security Block             | This document  |
      +-------+--------------------------------------+----------------+

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Ciphersuite Numbers</span>

   This protocol has a ciphersuite number field and certain ciphersuites
   are defined.  An IANA registry has been set up as follows.

   The registration policy for this registry is: Specification Required

   The Value range is: Variable Length

      Ciphersuite Numbers Registry:
      +-------+--------------------------------------+----------------+
      | Value | Description                          | Reference      |
      +-------+--------------------------------------+----------------+
      |     0 | unassigned                           | This document  |
      |     1 | BAB-HMAC                             | This document  |
      |     2 | PIB-RSA-SHA256                       | This document  |
      |     3 | PCB-RSA-AES128-PAYLOAD-PIB-PCB       | This document  |
      |     4 | ESB-RSA-AES128-EXT                   | This document  |
      |    &gt;4 | Reserved                             | This document  |
      +-------+--------------------------------------+----------------+

<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>.  Ciphersuite Flags</span>

   This protocol has a ciphersuite flags field and certain flags are
   defined.  An IANA registry has been set up as follows.

   The registration policy for this registry is: Specification Required

   The Value range is: Variable Length



<span class="grey">Symington, et al.             Experimental                     [Page 56]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-57" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


      Ciphersuite Flags Registry:
      +-----------------+----------------------------+----------------+
      |    Bit Position | Description                | Reference      |
      | (right to left) |                            |                |
      +-----------------+----------------------------+----------------+
      |               0 | Block contains result      | This document  |
      |               1 | Block contains correlator  | This document  |
      |               2 | Block contains parameters  | This document  |
      |               3 | Destination EIDref present | This document  |
      |               4 | Source EIDref present      | This document  |
      |              &gt;4 | Reserved                   | This document  |
      +-----------------+----------------------------+----------------+

<span class="h3"><a class="selflink" id="section-9.4" href="#section-9.4">9.4</a>.  Parameters and Results</span>

   This protocol has fields for ciphersuite-parameters and results.  The
   field is a type-length-value triple and a registry is required for
   the "type" sub-field.  The values for "type" apply to both the
   ciphersuite-parameters and the ciphersuite results fields.  Certain
   values are defined.  An IANA registry has been set up as follows.

   The registration policy for this registry is: Specification Required

   The Value range is: 8-bit unsigned integer

      Ciphersuite-Parameters and Results Type Registry:
      +---------+------------------------------------+----------------+
      | Value   | Description                        | Reference      |
      +---------+------------------------------------+----------------+
      |       0 | reserved                           | This document  |
      |       1 | initialization vector (IV)         | This document  |
      |       2 | reserved                           | This document  |
      |       3 | key-information                    | This document  |
      |       4 | fragment-range (pair of SDNVs)     | This document  |
      |       5 | integrity signature                | This document  |
      |       6 | unassigned                         | This document  |
      |       7 | salt                               | This document  |
      |       8 | PCB integrity check value (ICV)    | This document  |
      |       9 | reserved                           | This document  |
      |      10 | encapsulated block                 | This document  |
      |      11 | block type of encapsulated block   | This document  |
      |  12-191 | reserved                           | This document  |
      | 192-250 | private use                        | This document  |
      | 251-255 | reserved                           | This document  |
      +-------+--------------------------------------+----------------+






<span class="grey">Symington, et al.             Experimental                     [Page 57]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-58" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  References</span>

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Normative References</span>

   [<a id="ref-DTNBP">DTNBP</a>]    Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", <a href="./rfc5050">RFC 5050</a>, November 2007.

   [<a id="ref-DTNMD">DTNMD</a>]    Symington, S., "Delay-Tolerant Networking Metadata
              Extension Block", <a href="./rfc6258">RFC 6258</a>, May 2011.

   [<a id="ref-RFC2104">RFC2104</a>]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", <a href="./rfc2104">RFC 2104</a>,
              February 1997.

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC4055">RFC4055</a>]  Schaad, J., Kaliski, B., and R. Housley, "Additional
              Algorithms and Identifiers for RSA Cryptography for use in
              the Internet X.509 Public Key Infrastructure Certificate
              and Certificate Revocation List (CRL) Profile", <a href="./rfc4055">RFC 4055</a>,
              June 2005.

   [<a id="ref-RFC4106">RFC4106</a>]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
              (GCM) in IPsec Encapsulating Security Payload (ESP)",
              <a href="./rfc4106">RFC 4106</a>, June 2005.

   [<a id="ref-RFC5280">RFC5280</a>]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", <a href="./rfc5280">RFC 5280</a>, May 2008.

   [<a id="ref-RFC5652">RFC5652</a>]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              <a href="./rfc5652">RFC 5652</a>, September 2009.

   [<a id="ref-RFC6255">RFC6255</a>]  Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle
              Protocol IANA Registries", <a href="./rfc6255">RFC 6255</a>, May 2011.

<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  Informative References</span>

   [<a id="ref-DTNarch">DTNarch</a>]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Networking Architecture", <a href="./rfc4838">RFC 4838</a>, April 2007.

   [<a id="ref-PHIB">PHIB</a>]     Symington, S., "Delay-Tolerant Networking Previous-Hop
              Insertion Block", <a href="./rfc6259">RFC 6259</a>, May 2011.





<span class="grey">Symington, et al.             Experimental                     [Page 58]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-59" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


   [<a id="ref-RFC3986">RFC3986</a>]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              <a href="./rfc3986">RFC 3986</a>, January 2005.

   [<a id="ref-RFC5084">RFC5084</a>]  Housley, R., "Using AES-CCM and AES-GCM Authenticated
              Encryption in the Cryptographic Message Syntax (CMS)",
              <a href="./rfc5084">RFC 5084</a>, November 2007.

   [<a id="ref-RFC5751">RFC5751</a>]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", <a href="./rfc5751">RFC 5751</a>, January 2010.








































<span class="grey">Symington, et al.             Experimental                     [Page 59]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-60" ></span>
<span class="grey"><a href="./rfc6257">RFC 6257</a>                Bundle Security Protocol                May 2011</span>


Authors' Addresses

   Susan Flynn Symington
   The MITRE Corporation
   7515 Colshire Drive
   McLean, VA  22102
   US

   Phone: +1 (703) 983-7209
   EMail: susan@mitre.org
   URI:   <a href="http://mitre.org/">http://mitre.org/</a>


   Stephen Farrell
   Trinity College Dublin
   Distributed Systems Group
   Department of Computer Science
   Trinity College
   Dublin  2
   Ireland

   Phone: +353-1-896-2354
   EMail: stephen.farrell@cs.tcd.ie


   Howard Weiss
   SPARTA, Inc.
   7110 Samuel Morse Drive
   Columbia, MD  21046
   US

   Phone: +1-443-430-8089
   EMail: howard.weiss@sparta.com


   Peter Lovell
   SPARTA, Inc.
   7110 Samuel Morse Drive
   Columbia, MD  21046
   US

   Phone: +1-443-430-8052
   EMail: dtnbsp@gmail.com








Symington, et al.             Experimental                     [Page 60]
</pre>