tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6257

 Errata 
Experimental
Pages: 60
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

Bundle Security Protocol Specification

Part 1 of 3, p. 1 to 25
None       Next RFC Part

 


Top       ToC       Page 1 
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


                 Bundle Security Protocol Specification

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 Section 2
   of RFC 5741.

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

Page 2 
Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Top       Page 3 
Table of Contents

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

Top      ToC       Page 4 
1.  Introduction

   This document defines security features for the Bundle Protocol
   [DTNBP] 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.

1.1.  Related Documents

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

Top      ToC       Page 5 
      "Delay-Tolerant Networking Architecture" [DTNarch] defines the
      architecture for delay-tolerant networks, but does not discuss
      security at any length.

      The DTN Bundle Protocol [DTNBP] defines the format and processing
      of the blocks used to implement the Bundle Protocol, excluding the
      security-specific blocks defined here.

1.2.  Terminology

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

   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 [DTNBP], 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.

Top      ToC       Page 6 
   +---------v-|   +->>>>>>>>>>v-+     +->>>>>>>>>>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-+   +-^---------+
   |         >>>>>>>>^         >>>>>>>>>>^         >>>>>>>>^         |
   +-----------+   +------------+      +-------------+   +-----------+
   |                     |                    |                      |
   |<--  An Internet --->|                    |<--- An Internet  --->|
   |                     |                    |                      |

   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

Top      ToC       Page 7 
   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 Section 3.3.

   As required in [DTNBP], 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.

Top      ToC       Page 8 
   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.

2.  Security Blocks

   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 Section 2.2.

      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.

Top      ToC       Page 9 
   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.

2.1.  Abstract Security Block

   Many of the fields below use the "SDNV" type defined in [DTNBP].
   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 [DTNBP]).  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.

Top      ToC       Page 10 
   o  EID-references - composite field defined in [DTNBP] 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 Section 3.8 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.

Top      ToC       Page 11 
         +  Ciphersuite-parameters data - parameters to be used with the
            ciphersuite in use, e.g., a key identifier or initialization
            vector (IV).  See Section 2.6 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 Section 4, 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 Section 4.  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.

Top      ToC       Page 12 
   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 [DTNBP], 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.

Top      ToC       Page 13 
   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".

2.2.  Bundle Authentication Block

   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.

Top      ToC       Page 14 
      An EID-reference to the security-source MAY be present.  The
      security-source can also be specified as part of key-information
      described in Section 2.6 or another block such as the Previous-Hop
      Insertion Block [PHIB].  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 Section 2.6 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.

Top      ToC       Page 15 
2.3.  Payload Integrity Block

   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 Section 2.6.

      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.

Top      ToC       Page 16 
   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 Section 3.6.

   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.

2.4.  Payload Confidentiality Block

   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.

Top      ToC       Page 17 
   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 Section 2.6) 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

Top      ToC       Page 18 
      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 Section 2.6) 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 Section 2.6.

      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.

Top      ToC       Page 19 
   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 Section 2.6.  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

Top      ToC       Page 20 
   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.

2.5.  Extension Security Block

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

   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.

Top      ToC       Page 21 
   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 Section 2.4,
   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 Section 2.6.
      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.

2.6.  Parameters and Result Fields

   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.

Top      ToC       Page 22 
   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
      Section 2.7.

Top      ToC       Page 23 
   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 Section 2.7.

   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.

2.7.  Key Transport

   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 Section 2.6: key-information (item type 3)
   and integrity signature (item type 5).  The ciphersuite MUST define
   the details and format for these items.  To facilitate

Top      ToC       Page 24 
   interoperability, it is strongly RECOMMENDED that the implementations
   use the appropriate definitions from the Cryptographic Message Syntax
   (CMS) [RFC5652] 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.

2.8.  PIB and PCB Combinations

   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 Section 2.4 to ensure that parameters
      are protected in the case of super-encryption.

Top      ToC       Page 25 
      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 Section 4.3.)  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.



(page 25 continued on part 2)

Next RFC Part