tech-invite   World Map     

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

RFC 6257

 
 
 

Bundle Security Protocol Specification

Part 3 of 3, p. 42 to 60
Prev RFC Part

 


prevText      Top      Up      ToC       Page 42 
4.  Mandatory Ciphersuites

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

   In all uses of CMS eContent in this specification, the relevant
   eContentType to be used is id-data as specified in [RFC5652].

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

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

4.1.  BAB-HMAC

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

   BAB-HMAC uses the strict canonicalization algorithm in Section 3.4.1.

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

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

   The variant of HMAC to be used is HMAC-SHA1 as defined in [RFC2104].

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

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

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

   Security-parameters are OPTIONAL with this scheme, but if used, then
   the only field that can be present is key-information (see
   Section 2.6).

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

4.2.  PIB-RSA-SHA256

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

   PIB-RSA-SHA256 uses the mutable canonicalization algorithm in
   Section 3.4.2, with the security-result data field for only the
   "current" block being excluded from the canonical form.  The

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

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

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

   Implementations MUST support the use of the "SignedData" type as
   defined in [RFC5652], Section 5.1, with SignerInfo type
   SignerIdentifier containing the issuer and serial number of a
   suitable certificate.  The data to be signed is the output of the
   SHA256 mutable canonicalization process.

   RSA is used with SHA256 as specified for the id-sha256 signature
   scheme in [RFC4055], Section 5.  The output of the signing process is
   the SignatureValue field for the PIB.

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

4.3.  PCB-RSA-AES128-PAYLOAD-PIB-PCB

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

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

   Encryption is done using the AES algorithm in Galois/Counter Mode
   (GCM) as described in [RFC5084].  Note: parts of the following
   description are borrowed from [RFC4106].

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

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

   For consistency with the description in [RFC5084], we refer to the
   GCM IV as a nonce.  The same key and nonce combination MUST NOT be
   used more than once.  The nonce has the following layout:

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

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

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

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

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

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

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

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

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

   Security-parameters

      key-information

      salt

      IV (this instance applies only to payload)

      fragment offset and length, if bundle is a fragment

   Security-result

      ICV

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

   Security-parameters

      IV for this specific block

   Security-result

      encapsulated block

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

Top      Up      ToC       Page 47 
   Implementations MUST support use of "enveloped-data" type as defined
   in [RFC5652], Section 6, with RecipientInfo type
   KeyTransRecipientInfo containing the issuer and serial number of a
   suitable certificate.  They MAY support additional RecipientInfo
   types.  The "encryptedContent" field in EncryptedContentInfo contains
   the encrypted BEK that protects the payload and certain security
   blocks of the bundle.

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

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

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

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

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

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

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

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

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

4.4.  ESB-RSA-AES128-EXT

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

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

   Encryption is done using the AES algorithm in Galois/Counter Mode
   (GCM) as described in [RFC5084].  Note: parts of the following
   description are borrowed from [RFC4106].

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

   For consistency with the description in [RFC5084], we refer to the
   GCM IV as a nonce.  The same key and nonce combination MUST NOT be
   used more than once.  The nonce has the following layout:

Top      Up      ToC       Page 49 
   +----------------+----------------+---------------------------------+
   |                               salt                                |
   +----------------+----------------+---------------------------------+
   |                                                                   |
   |                      initialization vector                        |
   |                                                                   |
   +----------------+----------------+---------------------------------+

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

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

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

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

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

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

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

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

Top      Up      ToC       Page 50 
   Security-parameters

      key-information

      salt

      IV for this specific block

      block type of encapsulated block (OPTIONAL)

   Security-result

      encapsulated block

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

   Security-parameters

      IV for this specific block

      block type of encapsulated block (OPTIONAL)

   Security-result

      encapsulated block

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

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

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

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

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

5.  Key Management

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

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

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

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

6.  Default Security Policy

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

      Under what conditions received bundles SHALL be forwarded.

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

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

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

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

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

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

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

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

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

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

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

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

      The mandatory ciphersuites MUST be used.

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

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

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

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

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

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

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

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

      If a received bundle does not satisfy the node's security policy
      for any reason, then the bundle MUST be discarded and processed no
      further; in this case, a bundle deletion status report (see the
      Bundle Protocol Specification [DTNBP]) indicating the failure MAY
      be generated.

7.  Security Considerations

   The Bundle Security Protocol builds upon much work of others, in
   particular, "Cryptographic Message Syntax (CMS)" [RFC5652] and
   "Internet X.509 Public Key Infrastructure Certificate and Certificate
   Revocation List (CRL) Profile" [RFC5280].  The security
   considerations in these two documents apply here as well.

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

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

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

   On the other hand, if the intent is to reduce the threat of denial-
   of-service attacks, then signing the encrypted message is
   appropriate.  A message that fails the signature check will not be
   processed through the computationally intensive decryption pass.  A
   more extensive discussion of these points is in S/MIME 3.2 Message
   Specification [RFC5751], especially in Section 3.6.

   Additional details relating to these combinations can be found in
   Section 2.8 where it is RECOMMENDED that the encrypt-then-sign
   combination is usually appropriate for usage in a DTN.

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

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

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

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

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

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

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

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

8.  Conformance

   As indicated above, this document describes both BSP and
   ciphersuites.  A conformant implementation MUST implement both BSP
   support and the four ciphersuites described in Section 4.  It MAY
   also support other ciphersuites.

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

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

Top      Up      ToC       Page 56 
9.  IANA Considerations

   This protocol has fields that have been registered by IANA.

9.1.  Bundle Block Types

   This specification allocates four codepoints from the existing
   "Bundle Block Types" registry defined in [RFC6255].

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

9.2.  Ciphersuite Numbers

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

   The registration policy for this registry is: Specification Required

   The Value range is: Variable Length

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

9.3.  Ciphersuite Flags

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

   The registration policy for this registry is: Specification Required

   The Value range is: Variable Length

Top      Up      ToC       Page 57 
      Ciphersuite Flags Registry:
      +-----------------+----------------------------+----------------+
      |    Bit Position | Description                | Reference      |
      | (right to left) |                            |                |
      +-----------------+----------------------------+----------------+
      |               0 | Block contains result      | This document  |
      |               1 | Block contains correlator  | This document  |
      |               2 | Block contains parameters  | This document  |
      |               3 | Destination EIDref present | This document  |
      |               4 | Source EIDref present      | This document  |
      |              >4 | Reserved                   | This document  |
      +-----------------+----------------------------+----------------+

9.4.  Parameters and Results

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

   The registration policy for this registry is: Specification Required

   The Value range is: 8-bit unsigned integer

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

Top      Up      ToC       Page 58 
10.  References

10.1.  Normative References

   [DTNBP]    Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

   [DTNMD]    Symington, S., "Delay-Tolerant Networking Metadata
              Extension Block", RFC 6258, May 2011.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
              (GCM) in IPsec Encapsulating Security Payload (ESP)",
              RFC 4106, June 2005.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009.

   [RFC6255]  Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle
              Protocol IANA Registries", RFC 6255, May 2011.

10.2.  Informative References

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

   [PHIB]     Symington, S., "Delay-Tolerant Networking Previous-Hop
              Insertion Block", RFC 6259, May 2011.

Top      Up      ToC       Page 59 
   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC5084]  Housley, R., "Using AES-CCM and AES-GCM Authenticated
              Encryption in the Cryptographic Message Syntax (CMS)",
              RFC 5084, November 2007.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

Top      Up      ToC       Page 60 
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-896-2354
   EMail: stephen.farrell@cs.tcd.ie


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

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


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

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