[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 6257

DTN Research Group                                          S. Symington
Internet-Draft                                     The MITRE Corporation
Expires: October 26, 2007                                     S. Farrell
                                                  Trinity College Dublin
                                                                H. Weiss
                                                               P. Lovell
                                                            SPARTA, Inc.
                                                          April 24, 2007


                 Bundle Security Protocol Specification
                  draft-irtf-dtnrg-bundle-security-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 26, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).










Symington, et al.       Expires October 26, 2007                [Page 1]


Internet-Draft          Bundle Security Protocol              April 2007


Abstract

   This document defines the bundle security protocol, which provides
   data integrity and confidentiality services.  We also describe
   various bundle security considerations including policy options.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Related Documents  . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Security Blocks  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Abstract Security Block  . . . . . . . . . . . . . . . . .  7
     2.2.  Bundle Authentication Block  . . . . . . . . . . . . . . . 10
     2.3.  Payload Security Block . . . . . . . . . . . . . . . . . . 11
     2.4.  Confidentiality Block  . . . . . . . . . . . . . . . . . . 12
     2.5.  PSB and CB combinations  . . . . . . . . . . . . . . . . . 14
   3.  Security Processing  . . . . . . . . . . . . . . . . . . . . . 16
     3.1.  Nodes as policy enforcement points . . . . . . . . . . . . 16
     3.2.  Canonicalisation of bundles  . . . . . . . . . . . . . . . 16
     3.3.  Endpoint ID confidentiality  . . . . . . . . . . . . . . . 22
     3.4.  Bundles received from other nodes  . . . . . . . . . . . . 22
     3.5.  The At-Most-Once-Delivery Option . . . . . . . . . . . . . 24
     3.6.  Bundle Fragmentation and Reassembly  . . . . . . . . . . . 24
     3.7.  Reactive fragmentation . . . . . . . . . . . . . . . . . . 25
   4.  Mandatory Ciphersuites . . . . . . . . . . . . . . . . . . . . 27
     4.1.  BAB-HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 27
     4.2.  PSB-RSA-SHA256 . . . . . . . . . . . . . . . . . . . . . . 28
     4.3.  CB-RSA-AES128-PAYLOAD-PSB  . . . . . . . . . . . . . . . . 28
   5.  Key Management . . . . . . . . . . . . . . . . . . . . . . . . 30
   6.  Default Security Policy  . . . . . . . . . . . . . . . . . . . 31
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 35
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 35
   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
   Intellectual Property and Copyright Statements . . . . . . . . . . 39











Symington, et al.       Expires October 26, 2007                [Page 2]


Internet-Draft          Bundle Security Protocol              April 2007


1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].

   This document defines security features for the bundle protocol [2]
   intended for use in delay tolerant networks, in order to provide the
   DTN security services as described in the DTN Security Overview and
   Motivations document [8].

   The bundle protocol is used in DTNs which 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 that the DTN be protected from
   unauthorized use, and this stressed environment poses unique
   challenges on 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.

1.1.  Related Documents

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

      The Delay-Tolerant Network Architecture [9] defines the
      architecture for delay-tolerant networks, but does not discuss
      security at any length.

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

      The Delay-Tolerant Networking Security Overview [8] provides an
      informative overview and high-level description of DTN security.




Symington, et al.       Expires October 26, 2007                [Page 3]


Internet-Draft          Bundle Security Protocol              April 2007


1.2.  Terminology

   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.

   In the figure below, which is adapted from figure 1 in the Bundle
   Protocol Specification, 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.




   +---------v-|   +->>>>>>>>>>v-+     +->>>>>>>>>>v-+   +-^---------+
   |BN1      v |   | ^   BN2   v |     | ^   BN3   v |   | ^  BN4    |
   +---------v-+   +-^---------v-+     +-^---------v-+   +-^---------+
   |Trans1   v |   + ^  T1/T2  v |     + ^  T2/T3  v |   | ^  Trans3 |
   +---------v-+   +-^---------v-+     +-^---------v +   +-^---------+
   |Net1     v |   | ^  N1/N2  v |     | ^  N2/N3  v |   | ^  Net3   |
   +---------v-+   +-^---------v +     +-^---------v-+   +-^---------+
   |         >>>>>>>>^         >>>>>>>>>>^         >>>>>>>>^         |
   +-----------+   +------------+      +-------------+   +-----------+
   |                     |                    |                      |
   |<--  An Internet --->|                    |<--- An Internet  --->|
   |                     |                    |                      |

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

   Bundle Nodes Sit at the Application layer of the Internet Model.

                                 Figure 1

   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



Symington, et al.       Expires October 26, 2007                [Page 4]


Internet-Draft          Bundle Security Protocol              April 2007


   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

   Referring to figure 1 again:

   If the bundle that originates at BN1 as source 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 as source 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 as source 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.

   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.

   Forwarding nodes MUST transmit blocks in the same order as they were
   received.  This requirement applies to all dtn nodes, not just ones
   which implement security processing.  Blocks in a bundle may be added
   or deleted according to the applicable specification, but blocks
   which are received and then transmitted MUST remain in the same
   relative order.





Symington, et al.       Expires October 26, 2007                [Page 5]


Internet-Draft          Bundle Security Protocol              April 2007


2.  Security Blocks

   There are three types of security blocks that MAY be included in a
   bundle.  These are the Bundle Authentication Block (BAB), the Payload
   Security Block (PSB), and the Confidentiality Block (CB).

      The BAB is used to assure the authenticity of the bundle along a
      single hop from forwarder to intermediate receiver.

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

      Since a BAB protects on a "hop-by-hop" basis and a PSB protects on
      a (sort of) "end-to-end" basis, 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 the PSB has
      been calculated and added to the bundle.

      The CB indicates that some parts of the bundle have been encrypted
      while en route between the CB security-source and the CB security-
      destination.

   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:

      - Block type code

      - Block processing control flags

      - Block EID reference list (optional)

      - Block data length

      - Block-type-specific data fields

   Since the three 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
   which are present/absent in an ASB.  Note that no bundle ever
   contains an ASB, which is simply a specification artifact.



Symington, et al.       Expires October 26, 2007                [Page 6]


Internet-Draft          Bundle Security Protocol              April 2007


2.1.  Abstract Security Block

   An ASB consists of the following mandatory and optional fields:

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

         BAB: 0x02

         PSB: 0x03

         CB: 0x04

      - Block processing control flags (SDNV) - defined as in all bundle
      protocol blocks except the primary bundle block (as described in
      the Bundle Protocol [2]).  SDNV encoding is described in the
      bundle protocol.  There are no constraints on the use of the block
      processing flags.[Comment.1]

      - EID references - composite field defined in [2] containing
      references to one or two EIDs.  Presence of EIDs is indicated by
      by the setting of bit 6 ("block contains an EID-reference field")
      of the block processing control flags.  If one or more is present,
      flags in the ciphersuite ID field, described below, specify which.
      The possible EIDs are, in order:-

      - (optional) Security-source - specifies the security source for
      the service.  If this is omitted, then the source of the bundle is
      assumed to be the security-source.

      - (optional) Security-destination - specifies the security
      destination for the service.  If this is omitted, then the
      destination of the bundle is assumed to be the security-
      destination.

      Both EID fields may be omitted, in which case the composite field
      itself is empty, as defined in [2].  In this case neither count
      nor references appear, and bit 6 is not set.

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

      - Block-type-specific data fields as follows:

         - Ciphersuite ID - identifies the ciphersuite in use.  This is
         two bytes long, though the top five bits are used to indicate



Symington, et al.       Expires October 26, 2007                [Page 7]


Internet-Draft          Bundle Security Protocol              April 2007


         the presence or absence of the optional fields below.

         - (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 note
         in Section 3.6 with regard to correlator values in bundle
         fragments.

         - (optional) Ciphersuite parameters - compound field of next
         two items

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

            - Ciphersuite parameters data - parameters to be used with
            the ciphersuite in use, e.g. a key identifier or
            initialization vector (IV).  The encoding rules for this
            field are defined as part of the ciphersuite specification.

         - (optional) Security result - compound field of 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, MAC or ciphertext block key).


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

   The structure of an abstract security block

                                 Figure 2

   The ciphersuite ID is a 16-bit value with the top five bits
   indicating which of the optional fields are present (value = "1") or



Symington, et al.       Expires October 26, 2007                [Page 8]


Internet-Draft          Bundle Security Protocol              April 2007


   absent (value="0").  The remaining 11 bits indicate the ciphersuite.

   Some ciphersuites are specified in Section 4, which also specifies
   the rules which MUST be satisfied by ciphersuite specifications.
   Additional ciphersuites MAY be defined in separate specifications.

   The structure of the ciphersuite ID bytes 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.

      src - the most significant bit (bit 0) indicates whether the ASB
      contains the optional security-source-length and security-source
      fields.

      dest - bit 1 indicates whether the security-destination-length and
      security-destination fields are present or not.

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

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

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

      bits 5-15 represent the ciphersuite number, giving a maximum of
      2048 different ciphersuites.



   Ciphersuite ID
     Bit   Bit   Bit   Bit   Bit   Bit   Bit   Bit
      0     1     2     3     4     5          ...         15
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
   |src  |dest |parm |corr |res  | ciphersuite ID              |
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

                                 Figure 3

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



Symington, et al.       Expires October 26, 2007                [Page 9]


Internet-Draft          Bundle Security Protocol              April 2007


   BN1 is both the CB-source and the PSB-source of the bundle, and BN3
   is the CB-dest of the bundle.

   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 PSB and CB 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.

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.

      The ciphersuite ID MUST be documented as a hop-by-hop
      authentication-ciphersuite which 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.

      The security-source field SHOULD be present and, if it is present,
      it MUST identify the forwarder of the bundle.  (If the forwarding
      node is identified in another block of the bundle that the next
      hop supports, e.g., the Previous Hop Insertion Block, the
      forwarding node need not be identified in the BAB.)





Symington, et al.       Expires October 26, 2007               [Page 10]


Internet-Draft          Bundle Security Protocol              April 2007


      The security-destination field SHOULD NOT be present unless the
      ciphersuite requires this information (since the first node
      receiving the bundle ought be the one to validate the BAB).

      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 a security result
   fields.  The other optional fields MUST NOT be present.  Typically,
   this second instance of a BAB will be the last block of the bundle.

2.3.  Payload Security Block

   A PSB 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.

      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 more
      than one related instance of a PSB be present in the bundle.  The
      correlator MUST NOT be present if the ciphersuite only requires
      one instance of the PSB in the bundle.

      The ciphersuite parameters field MAY be present.

      The security-source field MAY be present.

      The security-destination field 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 PSB is required then this is handled



Symington, et al.       Expires October 26, 2007               [Page 11]


Internet-Draft          Bundle Security Protocol              April 2007


      in the same way as described for the BAB above.

   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
   destination that has access to the required keying information.

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

2.4.  Confidentiality Block

   A typical confidentiality ciphersuite will encrypt the payload using
   a randomly generated bundle encrypting key (BEK) and will use a CB
   security result to carry the BEK encrypted with some long term key
   encryption key (KEK). or well-known public key.  If neither the
   destination or security-destination resolves the key to use for
   decryption, the ciphersuite parameters field can be used to indicate
   the decryption key with which the BEK can be recovered.  Subsequent
   CB security results will contain blocks encrypted using the BEK if
   non-payload blocks are to be encrypted.

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

   Payload super-encryption is allowed.  If a CB ciphersuite supports
   such super-encryption, then the ciphersuite MUST provide an
   unambiguous way to do the decryption operations in the correct order
   (e.g. by encoding the "layer" information as a ciphersuite
   parameter).  This "in-place" encryption of payload bytes is so as to
   allow bundle payload fragmentation and re-assembly to operate without
   knowledge of whether encryption has occurred.  A side-effect of this
   "in-place" encryption is that the payload will typically be expanded
   by up-to a ciphertext blocksize if the bulk cipher is a block cipher.
   Another is that the 2nd application of confidentiality does not
   generally protect the parameters of the first which represent a
   vulnerability in some circumstances.

   A CB 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.




Symington, et al.       Expires October 26, 2007               [Page 12]


Internet-Draft          Bundle Security Protocol              April 2007


      The ciphersuite ID MUST be documented as a confidentiality-
      ciphersuite.

      The correlator MUST be present if more than one related CB
      instance is required.  More than one CB instance might be required
      if the payload is to be encrypted for more than one security-
      destination so as to be robust in the face of routing
      uncertainties.  These multiple CB instances, however, would not be
      related and would therefore not require correlators.  On the other
      hand, multiple related CB instances would be required if both the
      payload and the PSB blocks in the bundle were to be encrypted.
      These multiple CB instances would require correlators to associate
      them with each other.  The correlator MUST NOT be present if there
      are no related CB instances.

      The ciphersuite parameters field MAY be present

      The security-source field MAY be present.

      The security-destination field MAY be present (and typically will
      be).

      The security result MAY be present and normally represents an
      encrypted bundle encryption key or encrypted versions of bundle
      blocks other than the payload block.

   As was the case for the BAB and PSB, if the ciphersuite requires more
   than one instance of the CB, then the first occurrence 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 CB MAY
   appear in that CB.  For example, the security result field MAY (and
   probably will) be included in multiple related CB instances.
   Similarly, subsequent CBs might each contain a ciphersuite parameters
   field with an IV specific to that CB instance.

   Put another way: when a node is encrypting some (non-payload) blocks,
   it MUST first create a CB with the required ciphersuite ID,
   parameters etc. as specified above.  Typically, this CB will appear
   "early" in the bundle.  If this "first" CB doesn't contain all of the
   ciphertext, then it may be followed by other (correlated) CB, which
   MUST NOT repeat the ciphersuite parameters, security-source, or
   security-destination fields from the first CB.

   A CB ciphersuite may, or may not, specify which blocks are to be
   encrypted.  If the ciphersuite doesn't specify this, then the node is
   free to encrypt whichever blocks it wishes.  If a CB ciphersuite does



Symington, et al.       Expires October 26, 2007               [Page 13]


Internet-Draft          Bundle Security Protocol              April 2007


   specify which blocks are to be encrypted, then doing otherwise is an
   error.

   Since a single CB security result can contain the ciphertext for
   multiple (non-payload) plaintext blocks, the node simply catenates
   these plaintext blocks prior to encryption.  After decryption the
   recovered plaintext should then replace the CB in the bundle for
   further processing (e.g.  PSB verification).  This recovered
   plaintext MUST contain all the appropriate block type, processing
   flags and length information.  In other words delete the CB in
   question and place the recovered plaintext, which consists of
   additional (non-payload) blocks, in the bundle at the location from
   which the CB was deleted.

   Even if a to-be-encrypted block has the "discard" flag set, whether
   or not the CB'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 cannot be processed" flag.)

2.5.  PSB and CB combinations

   Given the above definitions, nodes are free to combine applications
   of PSB and CB in any way they wish - the correlator value allows for
   multiple applications of security services to be handled separately.

   However, there are some clear security problems that could arise when
   applying multiple services, for example, if we encrypted a payload
   but left a PSB security result containing a signature in clear, this
   would allow payload guesses to 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 which applies to one
   instance of a PSB or CB, must be applied to all instances with the
   same correlator.

   We now list the PSB and CB combinations which we envisage as being
   useful to support:

      Encrypted tunnels - a single bundle may be encrypted many times
      en-route to its destination.  Clearly it must 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 CB, but with the payload
      encrypted multiple times, "in-place".





Symington, et al.       Expires October 26, 2007               [Page 14]


Internet-Draft          Bundle Security Protocol              April 2007


      Multiple parallel authenticators - a single security source might
      wish to integrity protect a bundle in multiple ways, in the hope
      that one of them will be useful.  This could be required if the
      path the bundle will take 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 PSB which 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 on each forwarding node adding its own PSB.  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 PSBs will likely be layered, so that each protects the
      earlier applications of PSB.

      Authenticated and encrypted bundles - a single bundle may require
      both authenticity and confidentiality.  In this case, most
      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 CB-RSA-AES128-
      PAYLOAD-PSB ciphersuite defined later in Section 4.3.)

   There are no doubt other valid ways to combine PSB and CB instances,
   but these are the "core" set we wish to support.  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 in order to keep this
   specification as simple as possible, while at the same time
   supporting the above scenarios.














Symington, et al.       Expires October 26, 2007               [Page 15]


Internet-Draft          Bundle Security Protocol              April 2007


3.  Security Processing

   This section describes the security aspects of bundle processing.

3.1.  Nodes as policy enforcement points

   All nodes are REQUIRED to have and enforce their own configurable
   security policies, whether these policies be explicit or default, as
   defined in Section 6.

   All nodes serve as Policy Enforcement Points (PEP) insofar as they
   enforce polices that may restrict the permissions of bundle nodes to
   inject traffic into the network.  If a particular transmission
   request satisfies the node's policy 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 of
   this document.[Comment.3]

   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 which always attempts to attach a PSB.
   Similarly it is also valid to implement a node which always rejects
   all requests which imply the use of a PSB.

   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 valid BAB, PSB or CB.  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, destined for the
   forwarding node's own endpoint.[Comment.4]

   The node's policy MAY call for the node to add or subtract some
   security blocks, for example, requiring the node attempt to encrypt
   (parts of) the bundle for some security-destination, or requiring
   that the node add a PSB.  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.

3.2.  Canonicalisation of bundles

   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 SHOULD NOT change the



Symington, et al.       Expires October 26, 2007               [Page 16]


Internet-Draft          Bundle Security Protocol              April 2007


   encoding of any URI 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 PSB) must be defined.

   This section defines two bundle canonicalisation algorithms which can
   be used by various ciphersuites.

3.2.1.  Strict canonicalisation

   The first algorithm which can be used basically permits no changes at
   all to the bundle between when it is forwarded at the security-source
   and when it is received at the security-destination and is mainly
   intended for use in BAB ciphersuites.  This algorithm simply involves
   catenating all blocks in the order presented, but omits all security
   result fields which are present in blocks of the ciphersuite type in
   question - that is, when a BAB ciphersuite specifies this algorithm
   then we omit all BAB security results, when a PSB ciphersuite
   specifies this algorithm then we omit all PSB security results.  (All
   security result length fields are included, even though their
   corresponding security result length fields may be omitted.)

   Notes:

      - In the above we call for security results to be omitted.  This
      means that no bytes at all of the security result are input.  We
      do not set the security result length to zero.  Rather, we are
      assuming that the security result length will be known to the
      module that implements the ciphersuite before the security result
      is calculated, and that this value will be in the security result
      length field even though the security result itself will be
      omitted.

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

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

      -BABs are always added to bundles after PSBs, so when a PSB
      ciphersuite specifies this strict canonicalisation algorithm and
      the PSB is received with a bundle that also includes one or more
      BABs, application of strict canonicalisation as part of the PSB
      security result verification process requires that all BABs in the



Symington, et al.       Expires October 26, 2007               [Page 17]


Internet-Draft          Bundle Security Protocol              April 2007


      bundle be ignored entirely.

3.2.2.  Mutable canonicalisation

   This algorithm is mainly intended to protect parts of the bundle
   which should not be changed in-transit, and hence it omits the
   mutable parts of the bundle.

   The basic approach is to define a canonical form for the primary
   block, and catenate that with the security and payload blocks in the
   order that they will be transmitted.  This algorithm ignores all
   other blocks on the basis that we cannot tell whether or not they are
   liable to change as the bundle transits the network.

   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.

   The canoncial form of the primary block is shown below.  Essentially,
   it de-references the dictionary block, adjusts lengths where
   necessary and ignores flags that may change in transit.






























Symington, et al.       Expires October 26, 2007               [Page 18]


Internet-Draft          Bundle Security Protocol              April 2007


   +----------------+----------------+----------------+----------------+
   |    Version     |  Proc. Flags   |   COS Flags    |   SRR Flags    |
   +----------------+----------------+---------------------------------+
   |                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                              |
   +----------------+----------------+----------------+----------------+
   |                      Fragment offset (optional)                   |
   +----------------+----------------+---------------------------------+
   |            Total application data unit length (optional)          |
   +----------------+----------------+---------------------------------+

   The canonical form of the primary bundle block.

                                 Figure 4

   The fields shown are:

      Version, Processing Flags, COS, SRR - are all copied from the
      first four bytes of the primary block and will contain the version
      and the immutable flag values from the primary block.  Formed by
      copying the processing, COS and SRR flag fields from the primary
      block and then subsequently setting all of the mutable bits to
      zero.  This requires ANDing with the (four byte) value 0xFF3E031F
      so that the mutable and reserved bits are set to zero.  The only
      currently mutable bit masked out here is the "bundle is a



Symington, et al.       Expires October 26, 2007               [Page 19]


Internet-Draft          Bundle Security Protocol              April 2007


      fragment" bit - all others are reserved bits.  Note also that,
      since the flags fields are packed into an SDNV, adding a bit might
      change its length and thereby invalidate the signature even though
      the extra bit is not included in the canonicalization.  To prevent
      this error, canonicalization uses the non-SDNV form of the flags
      field, along with the appropriate mask.  As described in [2], the
      maximum size supported for SDNV encoding is 64 bits.
      Canonicalization therefore uses the 64-bit decoded value, masked
      as described above.

      There is an issue here which PSB ciphersuites MUST tackle.  If a
      bundle is fragmented before the PSB is applied then the PSB
      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
      by the PSB.  For this reason, PSB ciphersuites which support
      applying a PSB to fragments MUST specify which bytes of the bundle
      payload are protected as part of the ciphersuite parameters.  When
      verifying such a fragment only the bytes from the fragment are
      input to the PSB verification.  Of course, if is also valid for a
      ciphersuite to be specified so as to only apply to entire bundles
      and not to fragments.

      Length - a four-byte value containing the length (in bytes) of
      this structure.[Comment.5]

      Destination endpoint ID length and value - are the length (as a
      four byte value) 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 canonicalised.

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

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

      Creation time and Lifetime are simply copied from the primary
      block.

      Fragment offset and Total application data unit length are copied
      from the primary block if they are present there (which is
      controlled by one of the flags).

   Payload blocks are generally copied as-is, with the exception that
   the processing flags value in the canonical version MUST be ANDed
   with 0x37 to ensure that currently "reserved" flags are clear and
   that the "last block" flag is ignored.  The reason to ignore the



Symington, et al.       Expires October 26, 2007               [Page 20]


Internet-Draft          Bundle Security Protocol              April 2007


   "last block" flag is that if a bundle is created with both PSB and
   BAB, then the next hop will remove the BAB instances, and if one of
   those was the last block, it may set the "last block" flag of, e.g.,
   a PSB instance.  The "last block" flag is therefore a mutable bit and
   should be omitted from the canonical form.  Note that the "Block was
   forwarded without being processed" flag is included in the canonical
   form of the Payload Block because this flag is never expected to be
   set by any node; all nodes are required to be able to process the
   Payload Block.  The SDNV considerations described above for the
   primary block flags field apply also to the flags field of the
   payload and other non-primary blocks.

   Another exception occurs in cases where only a fragment of the
   payload was protected, when only those bytes of the payload block
   payload field are considered part of the canonical form.

   Security blocks are handled likewise, with two exceptions:

      - the "Block was forwarded without being processed" flag MUST be
      omitted from the canonical form of the PSB and the CB because this
      flag may be set by a node located between the security-source and
      the security-destination.  Therefore, the processing flags value
      of the PSB and the CB in the canonical version MUST be ANDed with
      0x17 to ensure that the mutable "Block was forwarded without being
      processed" flag is ignored during canonicalization of these
      blocks.

      - 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 case in strict
      canonicalisation since we might use the mutable canonicalisation
      algorithm to handle sequential signatures, where later signatures
      should cover earlier ones.

   Notes:

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

      - We omit the reserved flags on the basis that we cannot determine
      whether or not they will change in transit.  This means that this
      algorithm may have to be revised if those flags are given a
      definition and if we want to protect them.

      - Our URI encoding does not preserve the "null-termination"
      convention from the dictionary field, nor do we separate the
      scheme and ssp as is done there.




Symington, et al.       Expires October 26, 2007               [Page 21]


Internet-Draft          Bundle Security Protocol              April 2007


      - Note that the URI encoding above will be a cause for errors if
      any node rewrites the dictionary for example changing the DNS part
      of some HTTP URL from lower-case to upper case.  This could happen
      transparently, for example, 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 exact general rules
      for canonicalising URIs (or even worse IRIs), this problem may be
      an unavoidable source of integrity failures.

      - All length fields here are four byte values in network byte
      order.  We do not need to optimize the encoding since the values
      are never sent over the network.

3.3.  Endpoint ID confidentiality

   Since every bundle MUST contain a primary block that cannot be
   encrypted, and which contains the source endpoint ID (and others), if
   we want to provide endpoint ID confidentiality, then we have to
   invent a fake primary block with false values for these fields and
   then a new block type to contain the actual values.

   Similarly, there may be confidentiality requirements applying to
   other parts of the primary block (e.g. the current-custodian) and we
   support these in the same way.

   Since we don't know if we'll do this...details are TBD:-)[Comment.6]

 3.4.   Bundles received from other nodes

   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 is not required to have a
   BAB, then BAB processing on the received bundle is complete and the
   bundle is ready to be further processed for CB/PSB handling or
   delivery or forwarding.

   If the bundle is required to have a BAB but it 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 different node
   other than the receiving node as the BAB security destination, then
   the bundle MUST be discarded and processed no further.

   Otherwise, if the bundle does have a BAB that either does not have a
   security destination field or that identifies the receiving node as
   the BAB security destination, then the value in the security result
   field of the BAB 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



Symington, et al.       Expires October 26, 2007               [Page 22]


Internet-Draft          Bundle Security Protocol              April 2007


   check fails, the bundle has failed to authenticate and the bundle
   SHALL be discarded and processed no further.  Otherwise, if any of
   the BABs present verify, the bundle is ready to have its CB processed
   (if it includes one).

   When forwarding a bundle that included some BABs when it was
   received, these BABs MUST be stripped from the bundle.  New BABs MAY
   be added as required by policy.  This might require correcting the
   "last block" field of the to-be-forwarded bundle.

   If the bundle has a CB and the receiving node is the CB destination
   for the bundle (either because the node is listed in the bundle's CB-
   dest field or because the node is listed as the bundle's destination
   and there is no CB-dest field), the node MUST decrypt the relevant
   parts of the bundle according to the ciphersuite specification and
   delete the CB in question.  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 [2]) indicating the decryption failure MAY be generated,
   destined for the receiving node's own endpoint.  If the CB security
   result included the ciphertext of anything other than an encrypted
   BEK that was used to encrypt the bundle payload, the recovered
   plaintext blocks MUST be placed in the bundle at the location from
   which the CB was deleted.

   If the bundle has a PSB and the receiving node is the PSB destination
   for the bundle (either because the node is listed in the bundle's
   PSB-dest field or because the node is listed as the bundle's
   destination and there is no PSB-dest field), the node MUST verify the
   value in the security result field of the PSB according to the
   ciphersuite specification.  If the check fails, the bundle has failed
   to authenticate and the bundle SHALL be discarded and processed no
   further; a bundle status report indicating the failure MAY be
   generated, destined for the receiving node's own endpoint.
   Otherwise, if the PSB verifies, the bundle is ready to be processed
   for either delivery or forwarding.  Before forwarding the bundle, the
   node SHOULD remove the PSB from the bundle, unless there is the
   likelihood that some downstream node will also be able to verify the
   PSB.

   If the bundle has a PSB and the receiving node is not the PSB-dest
   for the bundle but the ciphersuite allows, the receiving node MAY, if
   it is able, verify the value in the security result field.  If the
   check fails, the node SHALL discard the bundle and it MAY send a
   bundle status report indicating the failure to the receiving node's
   own endpoint.




Symington, et al.       Expires October 26, 2007               [Page 23]


Internet-Draft          Bundle Security Protocol              April 2007


3.5.  The At-Most-Once-Delivery Option

   An application may request (in some 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.

   We define a new option for use in such cases, known as "at-most-once-
   delivery".  If this option is chosen, then the application is
   indicating that it wants the node to check for duplicate bundles,
   discard duplicates, and deliver at most one copy of each received
   bundle to the application.  If this option is not chosen, the
   application is indicating 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 should uniquely identify a bundle,
   has been received before.  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.

   The duration for which a node maintains entries on such a list is an
   implementation matter.

   If any application has indicated that it wants a node to use the "at
   most once" delivery option for a particular destination endpoint ID
   that is in a bundle, then the node MUST compare the (source,
   timestamp, fragment offset, fragment length) values of the bundle
   with the local list of such values of already-received bundles.

   Additional discussion relevant to at-most-delivery is in the DTN
   Retransmission Block specification [10].

3.6.  Bundle Fragmentation and Reassembly

   If it is necessary for a node to fragment a bundle and security is
   being used on that bundle, the following security-specific processing
   is REQUIRED:

   Firstly, a BAB, PSB or CB MUST NOT be fragmented.  At this time, only
   the payload field of the payload block MAY be fragmented.

   If the bundle is required by the security policy to have a BAB before



Symington, et al.       Expires October 26, 2007               [Page 24]


Internet-Draft          Bundle Security Protocol              April 2007


   being forwarded, all fragments resulting from that bundle MUST
   contain individual BAB values.

   If the original bundle had a PSB, then each of the PSB instances MUST
   be included in some fragment.  A single PSB instance MUST NOT be sent
   more than once.

   If the original bundle had a CB, then the each of the CB instances
   MUST be included in some fragment.  A single CB instance MUST NOT be
   sent more than once.

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

3.7.  Reactive fragmentation

   When original bundle transmission is terminated before the entire
   bundle has been transmitted, the receiving node SHALL consult its
   security policy to determine whether it is permitted to transform the
   received portion of the bundle into a bundle fragment for further
   forwarding.  Whether or not such reactive fragmentation is permitted
   SHALL be dependent on the security policy in combination with the
   ciphersuite used to calculate the BAB authentication information if
   required.  (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC
   ciphersuite defined in Section 4.1, 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 original bundle is fragmented by the intermediate receiver
   (reactively), 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 an original bundle transmission is terminated before the entire
   bundle has been transmitted, if the truncated bundle arriving at the
   intermediate receiver 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



Symington, et al.       Expires October 26, 2007               [Page 25]


Internet-Draft          Bundle Security Protocol              April 2007


   fragment and, if the original bundle included a BAB, the fragmented
   bundle MUST also, and its BAB SHALL be recalculated.

   This specification does not currently define any ciphersuite which
   can handle this reactive fragmentation case well.














































Symington, et al.       Expires October 26, 2007               [Page 26]


Internet-Draft          Bundle Security Protocol              April 2007


4.  Mandatory Ciphersuites

   This section defines the mandatory ciphersuites for this
   specification.  There is currently one mandatory ciphersuite for each
   of BAB, PSB and CB.  The BAB ciphersuite is based on shared secrets
   using HMAC.  The PSB ciphersuite is based on digital signatures using
   RSA with SHA256.  The CB ciphersuite is based on using RSA for key
   transport and AES for bulk encryption.

4.1.  BAB-HMAC

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

   Security parameters are optional with this scheme, but if used then
   the value of the ciphersuite parameter MUST be used as a key
   identifier.  The exact type of key identifier to be used is an
   implementation issue.  In the absence of a key identifier the
   intermediate receiver is expected to be able to find the correct key
   based on the sending identity (from the security-source and/or
   convergence layer).

   BAB-HMAC uses the strict canonicalisation algorithm in Section 3.2.1.

   The variant of HMAC to be used is HMAC-SHA1 as defined in RFC 2104
   [3].[Comment.7]

   This ciphersuite requires the use of two related instances of the
   BAB.  It involves placing the first BAB instance (as defined in
   Section 2.2) 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 canonicalising.

   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 or 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
   input being the result of running the entire bundle through the
   strict canonicalisation algorithm.  Both required BAB instances MUST
   be included in the bundle before canonicalisation.



Symington, et al.       Expires October 26, 2007               [Page 27]


Internet-Draft          Bundle Security Protocol              April 2007


4.2.  PSB-RSA-SHA256

   The PSB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x002.

   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.  So, if the bundle is a
   fragment, then the ciphersuite parameters MUST include two SDNV
   encoded numbers, representing the offset and length of the signed
   fragment.  If the entire bundle is signed then these numbers MUST be
   omitted.

   The ciphersuite parameters field MAY also contain a key identifier.
   The exact type of key identifier to be used is an implementation
   issue.  In the absence of a key identifier the verifier of the PSB is
   expected to be able to use the security source (if supplied) or else
   the bundle source (if no security source is present) in order to
   determine the correct public key to use for PSB verification.

   PSB-RSA-SHA256 uses the mutable canonicalisation algorithm
   Section 3.2.2.  The resulting canonical form of the bundle is the
   input to the signing process.  This ciphersuite requires the use of a
   single instance of the PSB.

   RSA is used with SHA256 as specified for the sha256WithRSAEncryption
   PKCSv1.5 signature scheme in RFC 4055 [4].  The output of the signing
   process is the security result for the PSB.

   "Commensurate strength" cryptography is generally held to be a good
   idea.  A combination of RSA with SHA256 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 won't 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 that
   will be fine since we also expect that the hash function "issues"
   will be resolved before any standard would be derived from this
   protocol.[Comment.8]

 4.3.   CB-RSA-AES128-PAYLOAD-PSB
   [Comment.9]

   The CB-RSA-AES128-PAYLOAD-PSB ciphersuite has ciphersuite ID value
   0x003.

   This scheme only allows for payload and PSB encryption and involves
   encrypting every instance of a PSB as well as the payload.

   This ciphersuite requires the use of a single CB instance if the



Symington, et al.       Expires October 26, 2007               [Page 28]


Internet-Draft          Bundle Security Protocol              April 2007


   bundle does not contain a PSB, and multiple CB instances if the
   bundle includes one or more PSBs.  A first CB is created which
   contains the encrypted bundle encryption key (BEK).  The key size for
   this ciphersuite is 128 bits.

   For the first CB, there MUST be a ciphersuite parameter which
   contains a 16 byte IV, optionally followed by a key identifier (whose
   format is again out of scope here).  (If the ciphersuite parameters
   length field has a value equal to 16, then the parameters data field
   consists of only a 16-bye IV.  If the ciphersuite parameters length
   field has a value greater than 16, then the ciphersuite parameters
   data field consists of a 16-byte IV followed by a key identifier, and
   the length of that key identifier is the value in the ciphersuite
   parameters length field minus 16.)  The security result contains the
   BEK encrypted using PKCSv1.5 rsaEncryption as specified in RFC 3370
   [5].

   For each subsequent PSB, the entire block is replaced by a CB that is
   correlated with the first CB and whose security result is the
   ciphertext form of the PSB, including the block type, etc.  The
   parameters field contains a 16-byte IV specific to this block.

   For the payload, only the bytes of the bundle payload field are
   affected, being replaced by ciphertext.

   We separately encrypt the payload and each of the PSB blocks, using
   the BEK and a different IV.  The IV for the payload is contained in
   the first CB, the IV for each of the PSBs is in the parameter field
   of the replacement C block.

   The BEK uses the AES algorithm in CBC mode as specified by the id-
   aes-cbc object identifier in RFC 3565 [6]
   [Comment.10][Comment.11][Comment.12]


















Symington, et al.       Expires October 26, 2007               [Page 29]


Internet-Draft          Bundle Security Protocol              April 2007


 5.   Key Management

   Since key management in delay tolerant networks is still a research
   topic we cannot provide much in the way of useful key management
   here.  However, solely in order to support implementation and
   testing, implementations SHOULD support:

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

      - The use of well-known RSA public keys for PSB-RSA-SHA256 and CB-
      RSA-AES128-PAYLOAD-PSB ciphersuites.

   Since endpoint IDs are URIs and URIs can be placed in X.509 [7]
   public key certificates (in the subjectAltName extension)
   implementations SHOULD support this way of distributing public keys.
   Implementations SHOULD NOT be very strict in how they process X.509
   though, for example, it would probably not be correct to insist on
   Certificate Revocation List (CRL) checking in many DTN contexts.

   Other than that, key management is for future study.






























Symington, et al.       Expires October 26, 2007               [Page 30]


Internet-Draft          Bundle Security Protocol              April 2007


6.  Default Security Policy

   Every node serves as a Policy Enforcement Point (PEP) 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.

      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 PSBs and/or CBs.

      Under what conditions the authentication information provided in a
      bundle's PSB 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 PSB SHALL be added to a received bundle
      before that bundle is forwarded.

      Under what conditions a CB SHALL be added to 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.  [Comment.13]

   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.





Symington, et al.       Expires October 26, 2007               [Page 31]


Internet-Draft          Bundle Security Protocol              April 2007


      The mandatory ciphersuites MUST be used.

      All bundles received MUST have a BAB which 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, destined for the receiving node's own endpoint.

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

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

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

      A CB 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 PSB-destination
      field but the value in that PSB-destination field 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 [2]) indicating the failure SHOULD be generated,
      destined for the receiving node's own endpoint.













Symington, et al.       Expires October 26, 2007               [Page 32]


Internet-Draft          Bundle Security Protocol              April 2007


7.  Security Considerations
   [Comment.14]

   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 may 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 PSB-dest is not the same as its destination, then some
   node other than the destination (the node identified as the PSB-dest)
   is expected to validate the PSB security result while the bundle is
   en route.  However, if for some reason the PSB is not validated,
   there is no way for the destination to become aware of this.
   Typically, a PSB-dest will remove the PSB from the bundle after
   verifying the PSB and before forwarding it.  However, if there is a
   possibility that the PSB will also be verified at a downstream node,
   the PSB-dest will leave the PSB in the bundle.  Therefore, if a
   destination receives a bundle with a PSB that has a PSB-dest (which
   isn't the destination), this may, but does not necessarily, indicate
   a possible problem.

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







Symington, et al.       Expires October 26, 2007               [Page 33]


Internet-Draft          Bundle Security Protocol              April 2007


8.  IANA Considerations

   None at this time.  If the bundle protocol becomes a standards track
   protocol, then we may want to consider having IANA establish a
   register of block types, and in particular for this specification a
   separate register of ciphersuite specifications.













































Symington, et al.       Expires October 26, 2007               [Page 34]


Internet-Draft          Bundle Security Protocol              April 2007


9.  References

9.1.  Normative References

   [1]   Bradner, S. and J. Reynolds, "Key words for use in RFCs to
         Indicate Requirement Levels", RFC 2119, October 1997.

   [2]   Scott, K. and S. Burleigh, "Bundle Protocol Specification",
         draft-irtf-dtnrg-bundle-spec-09.txt, work-in-progress,
         April 2007.

   [3]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.

   [4]   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", RFC 4055, June 2005.

   [5]   Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
         RFC 3370, August 2002.

   [6]   Schaad, J., "Use of the Advanced Encryption Standard (AES)
         Encryption Algorithm in Cryptographic Message Syntax (CMS)",
         RFC 3565, July 2003.

   [7]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.

9.2.  Informative References

   [8]   Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant
         Network Security Overview",
         draft-irtf-dtnrg-sec-overview-03.txt, work-in-progress,
         April 2007.

   [9]   Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A., Scott,
         K., Torgerson, L., and H. Weiss, "Delay-Tolerant Network
         Architecture", RFC 4838, April 2007.

   [10]  Symington, S., "Delay-Tolerant Network Retransmission Block",
         draft-irtf-dtnrg-bundle-retrans-00.txt, work-in-progress,
         April 2007.







Symington, et al.       Expires October 26, 2007               [Page 35]


Internet-Draft          Bundle Security Protocol              April 2007


Editorial Comments

   [Comment.1]   Stephen: I guess there could be some weird corner case
                 where a  CB ciphersuite using counter-mode would allow
                 fragments to be individually decrypted, and in that
                 case, we might want to set replication for each
                 fragment. So we can't fully rule out setting that flag
                 for all PSB/CB.

   [Comment.2]   Stephen: This to be revisited!

   [Comment.3]   Stephen: Do we need to specify error handling for the
                 case where a node drops a bundle for policy reasons?
                 Does/can it signal back to the source that its done so?

   [Comment.4]   Howie: The security policy database will need to be
                 discussed somewhere. Does it belong in this document,
                 the bundle protocol spec., both, some other document?

   [Comment.5]   Editors: Check that mask value at the very last moment
                 (incl. during auth-48) to be sure its (still) correct.

   [Comment.6]   Stephen: Should we support source confidentiality?
                 Might complicate PSB which is the downside IMO.

   [Comment.7]   Editors: At the moment there appears to be no security
                 reason to move away from HMAC-SHA1 since the HMAC
                 construct is not as far as we know affected by
                 collisions in the underlying digest algorithm (which
                 are nearly practically computable for SHA-1).
                 Nevertheless, since we use SHA-256 in the signature
                 ciphersuite (since collisions do matter there), it may
                 be desirable to move to HMAC-SHA-256 as specified in
                 RFC 4321. So if you're writing code based on this...be
                 warned!

   [Comment.8]   Editors: There are currently unresolved "issues" with
                 digest algorithms which might cause a change here prior
                 to, but more likely, after, an RFC has issued. So
                 expect change!

   [Comment.9]   Editors: This entire section is to be treated as a
                 strawman for the present.

   [Comment.10]  Speculation: There would be an interesting possibility
                 opened up were we to use a stream cipher with the REK.
                 That is that we could then encrypt and decrypt
                 independently - Alice could encrypt for Bob, then



Symington, et al.       Expires October 26, 2007               [Page 36]


Internet-Draft          Bundle Security Protocol              April 2007


                 Charlie could encrypt for Dessie, then Bob could
                 decrypt, then Dessie. Better in terms of not adding
                 padding but worse in that it trivially allows known
                 plaintext manipulation if there's no PSB.

   [Comment.11]  Editors: Another option might also be to switch to
                 using counter mode rather than CBC which would have the
                 benefit of allowing some fragments to be decrypted even
                 if not all fragments arrive. While that seems nice
                 enough to do, it would of course require us to think
                 more about fragments and so is for the next version if
                 at all.

   [Comment.12]  Peter: there does not seem to be a suitable CTR mode
                 implementation for AES but perhaps CFB (also stream
                 mode) would be suitable. It also avoids padding.

   [Comment.13]  Howie: Eventually we will need to state where the
                 security policy information/DB does get discussed/
                 specified.

   [Comment.14]  Editors: Much more text is needed here no doubt.





























Symington, et al.       Expires October 26, 2007               [Page 37]


Internet-Draft          Bundle Security Protocol              April 2007


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:   http://mitre.org/


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

   Phone: +353-1-608-1539
   Email: stephen.farrell@cs.tcd.ie


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

   Phone: +1-443-430-8089
   Email: hsw@sparta.com


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

   Phone: +1-443-430-8052
   Email: peter.lovell@sparta.com








Symington, et al.       Expires October 26, 2007               [Page 38]


Internet-Draft          Bundle Security Protocol              April 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Symington, et al.       Expires October 26, 2007               [Page 39]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/