Delay-Tolerant Networking                                   E.J. Birrane
Internet-Draft

Internet Engineering Task Force (IETF)                   E. Birrane, III
Request for Comments: 9173                                      A. White
Intended status:
Category: Standards Track                                      S. Heiner
Expires: 26
ISSN: 2070-1721                                                  JHU/APL
                                                            January 2022                                         JHU/APL
                                                            25 July 2021

                    BPSec

     Default Security Contexts
                   draft-ietf-dtn-bpsec-default-sc-11 for Bundle Protocol Security (BPSec)

Abstract

   This document defines default integrity and confidentiality security
   contexts that can be used with the Bundle Protocol Security Protocol (BPSec)
   implementations.  These security contexts are intended to be used for
   both for testing the interoperability of BPSec implementations and
   for providing basic security operations when no other security
   contexts are defined or otherwise required for a network.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 26 January 2022.
   https://www.rfc-editor.org/info/rfc9173.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info)
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Simplified Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Integrity Security Context BIB-HMAC-SHA2  . . . . . . . . . .   4
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Parameters  . . . . . . . . . . . . . . . . . . . . . . .   6
       3.3.1.  SHA Variant . . . . . . . . . . . . . . . . . . . . .   7
       3.3.2.  Wrapped Key . . . . . . . . . . . . . . . . . . . . .   7
       3.3.3.  Integrity Scope Flags . . . . . . . . . . . . . . . .   8
       3.3.4.  Enumerations  . . . . . . . . . . . . . . . . . . . .   8
     3.4.  Results . . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.5.  Key Considerations  . . . . . . . . . . . . . . . . . . .   9
     3.6.  Security Processing Considerations  . . . . . . . . . . .  10
     3.7.  Canonicalization Algorithms . . . . . . . . . . . . . . .  10
     3.8.  Processing  . . . . . . . . . . . . . . . . . . . . . . .  11
       3.8.1.  Keyed Hash Generation . . . . . . . . . . . . . . . .  11
       3.8.2.  Keyed Hash Verification . . . . . . . . . . . . . . .  12
   4.  Security Context BCB-AES-GCM  . . . . . . . . . . . . . . . .  13
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     4.3.  Parameters  . . . . . . . . . . . . . . . . . . . . . . .  16
       4.3.1.  Initialization Vector (IV)  . . . . . . . . . . . . .  16
       4.3.2.  AES Variant . . . . . . . . . . . . . . . . . . . . .  16
       4.3.3.  Wrapped Key . . . . . . . . . . . . . . . . . . . . .  17
       4.3.4.  AAD Scope Flags . . . . . . . . . . . . . . . . . . .  17
       4.3.5.  Enumerations  . . . . . . . . . . . . . . . . . . . .  18
     4.4.  Results . . . . . . . . . . . . . . . . . . . . . . . . .  19
       4.4.1.  Authentication Tag  . . . . . . . . . . . . . . . . .  19
       4.4.2.  Enumerations  . . . . . . . . . . . . . . . . . . . .  20
     4.5.  Key Considerations  . . . . . . . . . . . . . . . . . . .  20
     4.6.  GCM Considerations  . . . . . . . . . . . . . . . . . . .  21
     4.7.  Canonicalization Algorithms . . . . . . . . . . . . . . .  22
       4.7.1.  Cipher text related calculations  . . . . . . . . . .  22  Calculations Related to Ciphertext
       4.7.2.  Additional Authenticated Data . . . . . . . . . . . .  23
     4.8.  Processing  . . . . . . . . . . . . . . . . . . . . . . .  24
       4.8.1.  Encryption  . . . . . . . . . . . . . . . . . . . . .  24
       4.8.2.  Decryption  . . . . . . . . . . . . . . . . . . . . .  26
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
     5.1.  Security Context Identifiers  . . . . . . . . . . . . . .  27
     5.2.  Integrity Scope Flags . . . . . . . . . . . . . . . . . .  27
     5.3.  AAD Scope Flags . . . . . . . . . . . . . . . . . . . . .  28
     5.4.  Guidance for Designated Experts . . . . . . . . . . . . .  29
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
     6.1.  Key Management  . . . . . . . . . . . . . . . . . . . . .  30
     6.2.  Key Handling  . . . . . . . . . . . . . . . . . . . . . .  31
     6.3.  AES GCM . . . . . . . . . . . . . . . . . . . . . . . . .  31
     6.4.  AES Key Wrap  . . . . . . . . . . . . . . . . . . . . . .  32
     6.5.  Bundle Fragmentation  . . . . . . . . . . . . . . . . . .  32
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .  33
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  34
     A.1.  Example 1: 1 - Simple Integrity . . . . . . . . . . . . . . .  35
       A.1.1.  Original Bundle . . . . . . . . . . . . . . . . . . .  35
       A.1.2.  Security Operation Overview . . . . . . . . . . . . .  37
       A.1.3.  Bundle  Block Integrity Block  . . . . . . . . . . . . . . .  38
       A.1.4.  Final Bundle  . . . . . . . . . . . . . . . . . . . .  39
     A.2.  Example 2: 2 - Simple Confidentiality with Key Wrap . . . . .  39
       A.2.1.  Original Bundle . . . . . . . . . . . . . . . . . . .  39
       A.2.2.  Security Operation Overview . . . . . . . . . . . . .  40
       A.2.3.  Bundle  Block Confidentiality Block  . . . . . . . . . . . .  41
       A.2.4.  Final Bundle  . . . . . . . . . . . . . . . . . . . .  43
     A.3.  Example 3: 3 - Security Blocks from Multiple Sources  . . . .  43
       A.3.1.  Original Bundle . . . . . . . . . . . . . . . . . . .  43
       A.3.2.  Security Operation Overview . . . . . . . . . . . . .  45
       A.3.3.  Bundle  Block Integrity Block  . . . . . . . . . . . . . . .  45
       A.3.4.  Bundle  Block Confidentiality Block  . . . . . . . . . . . .  47
       A.3.5.  Final Bundle  . . . . . . . . . . . . . . . . . . . .  49
     A.4.  Example 4: 4 - Security Blocks with Full Scope  . . . . . . .  49
       A.4.1.  Original Bundle . . . . . . . . . . . . . . . . . . .  49
       A.4.2.  Security Operation Overview . . . . . . . . . . . . .  50
       A.4.3.  Bundle  Block Integrity Block  . . . . . . . . . . . . . . .  51
       A.4.4.  Bundle  Block Confidentiality Block  . . . . . . . . . . . .  52
       A.4.5.  Final Bundle  . . . . . . . . . . . . . . . . . . . .  55
   Appendix B.  CDDL Expression  . . . . . . . . . . . . . . . . . .  55
   Appendix C.  Acknowledgements . . . . . . . . . . . . . . . . . .  56
   Acknowledgments
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  56

1.  Introduction

   The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec] specification [RFC9172] provides
   inter-bundle integrity and confidentiality operations for networks
   deploying the Bundle Protocol (BP)
   [I-D.ietf-dtn-bpbis]. [RFC9171].  BPSec defines BP
   extension blocks to carry security information produced under the
   auspices of some security context.

   This document defines two security contexts (one for an integrity
   service and one for a confidentiality service) for populating BPSec
   Block Integrity Blocks (BIBs) and Block Confidentiality Blocks
   (BCBs).  This document assumes familiarity with the concepts and
   terminology associated with BP and BPSec, as these security contexts
   are used with BPSec security blocks and other BP blocks carried
   within BP bundles.

   These contexts generate information that MUST be encoded using the
   CBOR
   Concise Binary Object Representation (CBOR) specification documented
   in [RFC8949].

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Integrity Security Context BIB-HMAC-SHA2

3.1.  Overview

   The BIB-HMAC-SHA2 security context provides a keyed-hash Message
   Authentication Code (MAC) over a set of plain text plaintext information.  This
   context uses the Secure Hash Algorithm 2 (SHA-2) discussed in [SHS]
   combined with the HMAC Hashed Message Authentication Code (HMAC) keyed
   hash discussed in [RFC2104].  The combination of HMAC and SHA-2 as
   the integrity mechanism for this security context was selected for
   two reasons:

   1.  The use of symmetric keys allows this security context to be used
       in places where an asymmetric-key infrastructure (such as a
       public key infrastructure) might be impractical.

   2.  The combination HMAC-SHA2 represents a well-supported and well-
       understood integrity mechanism with multiple implementations
       available.

   BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the
   supported length of the SHA-2 hash value.  These variants correspond
   to "HMAC 256/256", "HMAC 384/384", HMAC 256/256, HMAC 384/384, and "HMAC 512/512" HMAC 512/512 as defined in
   [RFC8152] Table 7: HMAC 7
   ("HMAC Algorithm Values. Values") of [RFC8152].  The selection of which
   variant is used by this context is provided as a security context
   parameter.

   The output of the HMAC MUST be equal to the size of the SHA2 hashing
   function: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits
   for SHA-512.

   The BIB-HMAC-SHA2 security context MUST have the security context
   identifier specified in Section 5.1.

3.2.  Scope

   The scope of BIB-HMAC-SHA2 is the set of information used to produce
   the plain text plaintext over which a keyed hash is calculated.  This plain
   text plaintext
   is termed the "Integrity Protected Plain Text" (IPPT). "Integrity-Protected Plaintext (IPPT)".  The content of
   the IPPT is constructed as the concatenation of information whose
   integrity is being preserved from the BIB-HMAC-SHA2 security source
   to its security acceptor.  There are five types of information that
   can be used in the generation of the IPPT, based on how broadly the
   concept of integrity is being applied.  These five types of
   information, whether they are required, and why they are important
   for integrity, integrity are discussed as follows.

   Security target contents
      The contents of the block-type-specific data field of the security
      target MUST be included in the IPPT.  Including this information
      protects the security target data and is considered the minimal,
      required set of information for an integrity service on the
      security target.

   IPPT Scope scope
      The determination of which optional types of information were used
      when constructing the IPPT MUST, itself, MUST always be included in the IPPT.
      Including this information ensures that the scope of the IPPT
      construction at a security source matches the scope of the IPPT
      construction at security verifiers and security acceptors.

   Primary block
      The primary block identifies a bundle and, bundle, and once created, the
      contents of this block are immutable.  Changes to the primary
      block associated with the security target indicate that the
      security target (and BIB) might no longer be in the correct
      bundle.

      For example, if a security target and associated BIB are copied
      from one bundle to another bundle, the BIB might still contain a
      verifiable signature for the security target unless information
      associated with the bundle primary block is included in the keyed
      hash carried by the BIB.

      Including this information in the IPPT protects the integrity of
      the association of the security target with a specific bundle.

   Security target other

   Other fields of the security target
      The other fields of the security target include block
      identification and processing information.  Changing this
      information changes how the security target is treated by nodes in
      the network even when the "user data" of the security target are
      otherwise unchanged.

      For example, if the block processing control flags of a security
      target are different at a security verifier than they were
      originally set at the security source source, then the policy for
      handling the security target has been modified.

      Including this information in the IPPT protects the integrity of
      the policy and identification of the security target data.

   BIB other

   Other fields of the BIB
      The other fields of the BIB include block identification and
      processing information.  Changing this information changes how the
      BIB is treated by nodes in the network, even when other aspects of
      the BIB are unchanged.

      For example, if the block processing control flags of the BIB are
      different at a security verifier than they were originally set at
      the security source, then the policy for handling the BIB has been
      modified.

      Including this information in the IPPT protects the integrity of
      the policy and identification of the security service in the
      bundle.

         |  NOTE: The security context identifier and security context
         |  parameters of the security block are not included in the
         |  IPPT because these parameters, by definition, are required
         |  to verify or accept the security service.  Successful
         |  verification at security verifiers and security acceptors
         |  implies that these parameters were unchanged since being
         |  specified at the security source.  This is the case because
         |  keys cannot be re-used reused across security contexts, contexts and because
         |  the integrity scope flags used to define the IPPT are
         |  included in the IPPT itself.

   The scope of the BIB-HMAC-SHA2 security context is configured using
   an optional security context parameter.

3.3.  Parameters

   BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants,
   communicate key information, and define the scope of the IPPT.

3.3.1.  SHA Variant

   This optional parameter identifies which variant of the SHA-2
   algorithm is to be used in the generation of the authentication code.

   This value MUST be encoded as a CBOR unsigned integer.

   Valid values for this parameter are as follows.

   SHA Variant Parameter Values

             +=======+======================================+

            +=======+========================================+
            | Value |              Description               |
             +=======+======================================+
            +=======+========================================+
            |   5   | HMAC 256/256 as defined in [RFC8152] Table 7     |
            |       |    Table 7: HMAC ("HMAC Algorithm Values Values") of [RFC8152] |
             +-------+--------------------------------------+
            +-------+----------------------------------------+
            |   6   | HMAC 384/384 as defined in [RFC8152] Table 7     |
            |       |    Table 7: HMAC ("HMAC Algorithm Values Values") of [RFC8152] |
             +-------+--------------------------------------+
            +-------+----------------------------------------+
            |   7   | HMAC 512/512 as defined in [RFC8152] Table 7     |
            |       |    Table 7: HMAC ("HMAC Algorithm Values Values") of [RFC8152] |
             +-------+--------------------------------------+
            +-------+----------------------------------------+

                  Table 1 1: SHA Variant Parameter Values

   When not provided, implementations SHOULD assume a value of 6
   (indicating use of HMAC 384/384), unless an alternate default is
   established by local security policy at the security source,
   verifiers, or acceptor of this integrity service.

3.3.2.  Wrapped Key

   This optional parameter contains the output of the AES key wrap
   authenticated encryption
   function (KW-AE) as defined in [RFC5649]. [RFC3394].  Specifically, this parameter holds
   the cipher text ciphertext produced when running the KW-AE this key wrap algorithm with the
   input string being the symmetric HMAC key used to generate the
   security results present in the security block.  The value of this
   parameter is used as input to the AES key wrap authenticated
   decryption function (KW-AD) at security verifiers and security acceptors to
   determine the symmetric HMAC key needed for the proper validation of
   the security results in the security block.

   This value MUST be encoded as a CBOR byte string.

   If this parameter is not present present, then security verifiers and
   acceptors MUST determine the proper key as a function of their local
   BPSec policy and configuration.

3.3.3.  Integrity Scope Flags

   This optional parameter contains a series of flags that describe what
   information is to be included with the block-type-specific data when
   constructing the IPPT value.

   This value MUST be represented as a CBOR unsigned integer, the value
   of which MUST be processed as a 16-bit field.  The maximum value of
   this field, as a CBOR unsigned integer, MUST be 65535.

   When not provided, implementations SHOULD assume a value of 7
   (indicating all assigned fields), unless an alternate default is
   established by local security policy at the security source,
   verifier, or acceptor of this integrity service.

   Implementations MUST set reserved and unassigned bits in this field
   to 0 when constructing these flags at a security source.  Once set,
   the value of this field MUST NOT be altered until the security
   service is completed at the security acceptor in the network and
   removed from the bundle.

   Bits in this field represent additional information to be included
   when generating an integrity signature over the security target.
   These bits are defined as follows.

      -

   Bit 0 (the low-order bit, 0x0001): Primary Block Flag.

      -  Include primary block flag

   Bit 1 (0x0002): Target Header Flag.

      -  Include target header flag

   Bit 2 (0x0004): Security Header Flag.

      -  Include security header flag

   Bits 3-7 are reserved.

      - 3-7:  Reserved

   Bits 8-15 are unassigned. 8-15:  Unassigned

3.3.4.  Enumerations

   The BIB-HMAC-SHA2 security context parameters are listed in Table 2.
   In this table, the "Parm Id" column refers to the expected Parameter
   Identifier parameter
   identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter ("Parameter and Result Identification".

   If the default value
   Identification") of [RFC9172].

   An empty "Default Value" column is empty, this indicates that the security context
   parameter does not have a default value.

   BIB-HMAC-SHA2 Security Parameters

      +=========+=============+====================+===============+
      | Parm Id | Parm Name   | CBOR Encoding Type | Default Value |
      +=========+=============+====================+===============+
      |    1    | SHA Variant | unsigned integer   |       6       |
      +---------+-------------+--------------------+---------------+
      |    2    | Wrapped Key |    Byte String byte string        |               |
      +---------+-------------+--------------------+---------------+
      |    3    | Integrity   | unsigned integer   |       7       |
      |         | Scope Flags |                    |               |
      +---------+-------------+--------------------+---------------+

            Table 2 2: BIB-HMAC-SHA2 Security Context Parameters

3.4.  Results

   The BIB-HMAC-SHA2 security context results are listed in Table 3.  In
   this table, the "Result Id" column refers to the expected Result
   Identifier result
   identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter ("Parameter and Result Identification".

   BIB-HMAC-SHA2 Security Results
   Identification") of [RFC9172].

       +========+==========+===============+======================+
       | Result |  Result  | CBOR Encoding |     Description      |
       |   Id   |   Name   |      Type     |                      |
       +========+==========+===============+======================+
       |   1    | Expected |  byte string  | The output of the    |
       |        |   HMAC   |               | HMAC calculation at  |
       |        |          |               | the security source. |
       +--------+----------+---------------+----------------------+

                 Table 3 3: BIB-HMAC-SHA2 Security Results

3.5.  Key Considerations

   HMAC keys used with this context MUST be symmetric and MUST have a
   key length equal to the output of the HMAC.  For this reason, HMAC
   key lengths will be integer integers divisible by 8 bytes bytes, and special padding-
   aware
   padding-aware AES key wrap algorithms are not needed.

   It is assumed that any security verifier or security acceptor
   performing an integrity verification can determine the proper HMAC
   key to be used.  Potential sources of the HMAC key include (but are
   not limited to) the following:

   *  Pre-placed keys selected based on local policy.

   *  Keys extracted from material carried in the BIB.

   *  Session keys negotiated via a mechanism external to the BIB.

   When an AES-KW AES Key Wrap (AES-KW) [RFC3394] wrapped key is present in a
   security block, it is assumed that security verifiers and security
   acceptors can independently determine the key encryption key (KEK)
   used in the wrapping of the symmetric HMAC key.

   As discussed in Section 6 and emphasized here, it is strongly
   recommended that keys be protected once generated, both when they are
   stored and when they are transmitted.

3.6.  Security Processing Considerations

   An HMAC calculated over the same IPPT with the same key will always
   have the same value.  This regularity can lead to practical side-
   channel attacks whereby an attacker could produce known plain text
   and a plaintext,
   guess at an HMAC tag tag, and observe the behavior of a verifier.  With a
   modest number of trials, a side-channel attack could produce an HMAC
   tag for attacher-provided plain text attacker-provided plaintext without the attacker ever knowing
   the HMAC key.

   A common method of observing the behavior of a verifier is precise
   analysis of the timing associated with comparisons.  Therefore, one
   way to prevent behavior analysis of this type is to ensure that any
   comparisons of the supplied and expected authentication tag occur in
   constant time.

   A constant-time comparison function SHOULD be used for the comparison
   of authentication tags by any implementation of this security
   context.  In cases where such a function is difficult or impossible
   to use, the impact of side-channel attacks (in general) and timing
   attacks (specifically) need to be considered as part of the
   implementation.

3.7.  Canonicalization Algorithms

   This section defines the canonicalization algorithm used to prepare
   the IPPT input to the BIB-HMAC-SHA2 integrity mechanism.  The
   construction of the IPPT depends on the settings of the integrity
   scope flags that can be provided as part of customizing the behavior
   of this security context.

   In all cases, the canonical form of any portion of an extension block
   MUST be performed created as described in [I-D.ietf-dtn-bpsec]. [RFC9172].  The canonicalization
   algorithms defined in [I-D.ietf-dtn-bpsec] [RFC9172] adhere to the canonical forms for
   extension blocks defined in
   [I-D.ietf-dtn-bpbis] [RFC9171] but resolve ambiguities related
   to how values are represented in CBOR.

   The IPPT is constructed using the following process.  While integrity
   scope flags might not be included in the BIB representing the
   security operation, they MUST be included in the IPPT value itself.

   1.  The canonical form of the IPPT starts as the CBOR encoding of the
       integrity scope flags in which all unset flags, reserved bits,
       and unassigned bits have been set to 0.  For example, if the
       primary block flag, target header flag, and security header flag
       are each set, then the initial value of the canonical form of the
       IPPT will be 0x07.

   2.  If the primary block flag of the integrity scope flags is set to
       1,
       1 and the security target is not the bundle's primary block, then
       a canonical form of the bundle's primary block MUST be calculated
       and the result appended to the IPPT.

   3.  If the target header flag of the integrity scope flags is set to
       1,
       1 and the security target is not the bundle's primary block, then
       the canonical form of the block type code, block number, and
       block processing control flags associated with the security
       target MUST be calculated and, in that order, appended to the
       IPPT.

   4.  If the security header flag of the integrity scope flags is set
       to 1, then the canonical form of the block type code, block
       number, and block processing control flags associated with the
       BIB MUST be calculated and, in that order, appended to the IPPT.

   5.  The canonical form of the security target block-type-specific
       data MUST be calculated and
       appended to the IPPT.  If the security target is the primary
       block, this is the canonical form of the primary block.
       Otherwise, this is the canonical form of the block-type-specific
       data of the security target.

      |  NOTE: When the security target is the bundle's primary block,
      |  the canonicalization steps associated with the primary block
      |  flag and the target header flag are skipped.  Skipping primary
      |  block flag processing, in this case, avoids adding the bundle's
      |  primary block twice in the IPPT calculation.  Skipping target
      |  header flag processing, in this case, is necessary because the
      |  primary block of a bundle does not have the expected elements
      |  of a block header such as block number and block processing
      |  control flags.

3.8.  Processing

3.8.1.  Keyed Hash Generation

   During keyed hash generation, two inputs are prepared for the the
   appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT.  These
   data items MUST be generated as follows.

   *  The HMAC key MUST have the appropriate length as required by local
      security policy.  The key can be generated specifically for this
      integrity service, given as part of local security policy, or
      obtained through some other key management mechanism as discussed
      in Section 3.5.

   *  Prior to the generation of the IPPT, if a CRC Cyclic Redundancy Check
      (CRC) value is present for the target block of the BIB, then that
      CRC value MUST be removed from the target block.  This involves
      both removing the CRC value from the target block and setting the
      CRC Type type field of the target block to "no CRC is present."

   *  Once CRC information is removed, the IPPT MUST be generated as
      discussed in Section 3.7.

   Upon successful hash generation generation, the following actions action MUST occur.

   *  The keyed hash produced by the HMAC/SHA2 variant MUST be added as
      a security result for the BIB representing the security operation
      on this security target, as discussed in Section 3.4.

   Finally, the BIB containing information about this security operation
   MUST be updated as follows.  These operations can occur in any order.

   *  The security context identifier for the BIB MUST be set to the
      context identifier for BIB-HMAC-SHA2.

   *  Any local flags used to generate the IPPT MUST be placed in the
      integrity scope flags security context parameter for the BIB
      unless these flags are expected to be correctly configured at
      security verifiers and acceptors in the network.

   *  The HMAC key MAY be included as a security parameter context parameter, in
      which case it MUST be wrapped using the NIST AES-KW algorithm AES key wrap function as
      defined in [RFC3394] and the results of the wrapping added as the
      wrapped key security context parameter for the BIB.

   *  The SHA variant used by this security context SHOULD be added as
      the SHA variant security context parameter for the BIB if it
      differs from the default key length.  Otherwise, this parameter
      MAY be omitted if doing so provides a useful reduction in message
      sizes.

   Problems encountered in the keyed hash generation MUST be processed
   in accordance with local BPSec security policy.

3.8.2.  Keyed Hash Verification

   During keyed hash verification, the input of the security target and
   a
   an HMAC key are provided to the appropriate HMAC/SHA2 algorithm.

   During keyed hash verification, two inputs are prepared for the
   appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT.  These
   data items MUST be generated as follows.

   *  The HMAC key MUST be derived using the wrapped key security
      context parameter if such a parameter is included in the security
      context parameters of the BIB.  Otherwise, this key MUST be
      derived in accordance with security policy at the verifying node
      as discussed in Section 3.5.

   *  The IPPT MUST be generated as discussed in Section 3.7 with the
      value of integrity scope flags being taken from the integrity
      scope flags security context parameter.  If the integrity scope
      flags parameter is not included in the security context parameters
      parameters, then these flags MAY be derived from local security
      policy.

   The calculated HMAC output MUST be compared to the expected HMAC
   output encoded in the security results of the BIB for the security
   target.  If the calculated HMAC and expected HMAC are identical, the
   verification MUST be considered a success.  Otherwise, the
   verification MUST be considered a failure.

   If the verification fails or otherwise experiences an error, error or if any
   needed parameters are missing, then the verification MUST be treated
   as failed and processed in accordance with local security policy.

   This security service is removed from the bundle at the security
   acceptor as required by the BPSec specification. specification [RFC9172].  If the
   security acceptor is not the bundle destination and if no other
   integrity service is being applied to the target block, then a CRC
   MUST be included for the target block.  The CRC type, as determined
   by policy, is set in the target block's CRC type field field, and the
   corresponding CRC value is added as the CRC field for that block.

4.  Security Context BCB-AES-GCM

4.1.  Overview

   The BCB-AES-GCM security context replaces the block-type-specific
   data field of its security target with cipher text ciphertext generated using the
   Advanced Encryption Standard (AES) cipher operating in Galois/
   Counter Galois/Counter
   Mode (GCM) [AES-GCM].  The use of AES-GCM was selected as the cipher
   suite for this confidentiality mechanism for several reasons:

   1.  The selection of a symmetric-key cipher suite allows for
       relatively smaller keys than asymmetric-key cipher suites.

   2.  The selection of a symmetric-key cipher suite allows this
       security context to be used in places where an asymmetric-key
       infrastructure (such as a public key infrastructure) might be
       impractical.

   3.  The use of the Galois/Counter Mode produces cipher-text ciphertext with the
       same size as the plain text plaintext making the replacement of target block
       information easier as length fields do not need to be changed.

   4.  The AES-GCM cipher suite provides authenticated encryption, as
       required by the BPSec protocol.

   Additionally, the BCB-AES-GCM security context generates an
   authentication tag based on the plain text plaintext value of the block-type-
   specific data and other additional authenticated data (AAD) that
   might be specified via parameters to this security context.

   This security context supports two variants of AES-GCM, based on the
   supported length of the symmetric key.  These variants correspond to
   A128GCM and A256GCM as defined in [RFC8152] Table 9: Algorithm 9 ("Algorithm Value for AES-GCM. AES-
   GCM") of [RFC8152].

   The BCB-AES-GCM security context MUST have the security context
   identifier specified in Section 5.1.

4.2.  Scope

   There are two scopes associated with BCB-AES-GCM: the scope of the
   confidentiality service and the scope of the authentication service.
   The first defines the set of information provided to the AES-GCM
   cipher for the purpose of producing cipher text. ciphertext.  The second defines
   the set of information used to generate an authentication tag.

   The scope of the confidentiality service defines the set of
   information provided to the AES-GCM cipher for the purpose of
   producing cipher text. ciphertext.  This MUST be the full set of plain text plaintext
   contained in the block-type-specific data field of the security
   target.

   The scope of the authentication service defines the set of
   information used to generate an authentication tag carried with the
   security block.  This information contains all data protected by the
   confidentiality service, service and the scope flags used to identify other
   optional information, and information; it MAY include other information (additional
   authenticated data), as follows.

   Primary block
      The primary block identifies a bundle and, bundle, and once created, the
      contents of this block are immutable.  Changes to the primary
      block associated with the security target indicate that the
      security target (and BCB) might no longer be in the correct
      bundle.

      For example, if a security target and associated BCB are copied
      from one bundle to another bundle, the BCB might still be able to
      decrypt the security target even though these blocks were never
      intended to exist in the copied-to bundle.

      Including this information as part of additional authenticated
      data ensures that the security target (and security block) appear
      in the same bundle at the time of decryption as at the time of
      encryption.

   Security target other

   Other fields of the security target
      The other fields of the security target include block
      identification and processing information.  Changing this
      information changes how the security target is treated by nodes in
      the network even when the "user data" of the security target are
      otherwise unchanged.

      For example, if the block processing control flags of a security
      target are different at a security verifier than they were
      originally set at the security source source, then the policy for
      handling the security target has been modified.

      Including this information as part of additional authenticated
      data ensures that the cipher text ciphertext in the security target will not
      be used with a different set of block policy than originally set
      at the time of encryption.

   BCB other

   Other fields of the BCB
      The other fields of the BCB include block identification and
      processing information.  Changing this information changes how the
      BCB is treated by nodes in the network, even when other aspects of
      the BCB are unchanged.

      For example, if the block processing control flags of the BCB are
      different at a security acceptor than they were originally set at
      the security source source, then the policy for handling the BCB has been
      modified.

      Including this information as part of additional authenticated
      data ensures that the policy and identification of the security
      service in the bundle has not changed.

         |  NOTE: The security context identifier and security context
         |  parameters of the security block are not included as
         |  additional authenticated data because these parameters, by
         |  definition, are those needed to verify or accept the
         |  security service.  Therefore, it is expected that changes to
         |  these values would result in failures at security verifiers
         |  and security acceptors.  This is the case because keys
         |  cannot be re-used reused across security
       contexts, contexts and because the
         |  AAD scope flags used to identify the AAD are included in the
         |  AAD.

   The scope of the BCB-AES-GCM security context is configured using an
   optional security context parameter.

4.3.  Parameters

   BCB-AES-GCM can be parameterized to specify the AES variant,
   initialization vector, key information, and identify additional
   authenticated data.

4.3.1.  Initialization Vector (IV)

   This optional parameter identifies the initialization vector (IV)
   used to initialize the AES-GCM cipher.

   The length of the initialization vector, prior to any CBOR encoding,
   MUST be between 8-16 bytes.  A value of 12 bytes SHOULD be used
   unless local security policy requires a different length.

   This value MUST be encoded as a CBOR byte string.

   The initialization vector can have any value value, with the caveat that a
   value MUST NOT be re-used reused for multiple encryptions using the same
   encryption key.  This value MAY be re-used reused when encrypting with
   different keys.  For example, if each encryption operation using BCB-
   AES-GCM uses a newly generated key, then the same IV can be reused.

4.3.2.  AES Variant

   This optional parameter identifies the AES variant being used for the
   AES-GCM encryption, where the variant is identified by the length of
   key used.

   This value MUST be encoded as a CBOR unsigned integer.

   Valid values for this parameter are as follows.

   AES Variant Parameter Values

             +=======+=======================================+

           +=======+===========================================+
           | Value |                Description                |
             +=======+=======================================+
           +=======+===========================================+
           |   1   | A128GCM as defined in [RFC8152] Table 9 ("Algorithm |
           |       | Table 9: Algorithm Values Value for AES-GCM AES-GCM") of [RFC8152]          |
             +-------+---------------------------------------+
           +-------+-------------------------------------------+
           |   3   | A256GCM as defined in [RFC8152] Table 9 ("Algorithm |
           |       | Table 9: Algorithm Values Value for AES-GCM AES-GCM") of [RFC8152]          |
             +-------+---------------------------------------+
           +-------+-------------------------------------------+

                   Table 4 4: AES Variant Parameter Values

   When not provided, implementations SHOULD assume a value of 3
   (indicating use of A256GCM), unless an alternate default is
   established by local security policy at the security source,
   verifier, or acceptor of this integrity service.

   Regardless of the variant, the generated authentication tag MUST
   always be 128 bits.

4.3.3.  Wrapped Key

   This optional parameter contains the output of the AES key wrap
   authenticated encryption
   function (KW-AE) as defined in [RFC5649]. [RFC3394].  Specifically, this parameter holds
   the cipher text ciphertext produced when running the KW-AE this key wrap algorithm with the
   input string being the symmetric AES key used to generate the
   security results present in the security block.  The value of this
   parameter is used as input to the AES key wrap authenticated
   decryption function (KW-AD) at security verifiers and security acceptors to
   determine the symmetric AES key needed for the proper decryption of
   the security results in the security block.

   This value MUST be encoded as a CBOR byte string.

   If this parameter is not present present, then security verifiers and
   acceptors MUST determine the proper key as a function of their local
   BPSec policy and configuration.

4.3.4.  AAD Scope Flags

   This optional parameter contains a series of flags that describe what
   information is to be included with the block-type-specific data of
   the security target as part of additional authenticated data (AAD).

   This value MUST be represented as a CBOR unsigned integer, the value
   of which MUST be processed as a 16-bit field.  The maximum value of
   this field, as a CBOR unsigned integer, MUST be 65535.

   When not provided, implementations SHOULD assume a value of 7
   (indicating all assigned fields), unless an alternate default is
   established by local security policy at the security source,
   verifier, or acceptor of this integrity service.

   Implementations MUST set reserved and unassigned bits in this field
   to 0 when constructing these flags at a security source.  Once set,
   the value of this field MUST NOT be altered until the security
   service is completed at the security acceptor in the network and
   removed from the bundle.

   Bits in this field represent additional information to be included
   when generating an integrity signature over the security target.
   These bits are defined as follows.

      -

   Bit 0 (the low-order bit, 0x0001): Primary Block Flag.

      -  Include primary block flag

   Bit 1 (0x0002): Target Header Flag.

      -  Include target header flag

   Bit 2 (0x0004): Security Header Flag.

      -  Include security header flag

   Bits 3-7 are reserved.

      - 3-7:  Reserved

   Bits 8-15 are unassigned. 8-15:  Unassigned

4.3.5.  Enumerations

   The BCB-AES-GCM security context parameters are listed in Table 5.
   In this table, the "Parm Id" column refers to the expected Parameter
   Identifier parameter
   identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter ("Parameter and Result Identification".

   If the default value
   Identification") of [RFC9172].

   An empty "Default Value" column is empty, this indicates that the security context
   parameter does not have a default value.

   BCB-AES-GCM Security Parameters

     +=========+================+====================+===============+
     | Parm Id |   Parm Name    | CBOR Encoding Type | Default Value |
     +=========+================+====================+===============+
     |    1    | Initialization |    Byte String    byte string     |               |
     |         |     Vector     |                    |               |
     +---------+----------------+--------------------+---------------+
     |    2    |  AES Variant   |  Unsigned Integer  unsigned integer  |       3       |
     +---------+----------------+--------------------+---------------+
     |    3    |  Wrapped Key   |    Byte String    byte string     |               |
     +---------+----------------+--------------------+---------------+
     |    4    |   AAD Scope    |  Unsigned Integer  unsigned integer  |       7       |
     |         |     Flags      |                    |               |
     +---------+----------------+--------------------+---------------+

              Table 5 5: BCB-AES-GCM Security Context Parameters

4.4.  Results

   The BCB-AES-GCM security context produces a single security result
   carried in the security block: the authentication tag.

   NOTES:

   *  The cipher text ciphertext generated by the cipher suite is not considered a
      security result as it is stored in the block-type-specific data
      field of the security target block.  When operating in GCM mode,
      AES produces cipher text ciphertext of the same size as its plain text and, plaintext;
      therefore, no additional logic is required to handle padding or
      overflow caused by the encryption in most cases (see below). cases.

   *  If the authentication tag can be separated from the cipher text, ciphertext,
      then the tag MAY be separated and stored in the authentication tag
      security result field.  Otherwise, the security target block MUST
      be resized to accommodate the additional 128 bits of
      authentication tag included with the generated cipher text ciphertext
      replacing the block-type-specific-data block-type-specific data field of the security
      target block.

4.4.1.  Authentication Tag

   The authentication tag is generated by the cipher suite over the
   security target plain text plaintext input to the cipher suite as combined with
   any optional additional authenticated data.  This tag is used to
   ensure that the plain text plaintext (and important information associated with
   the plain text) plaintext) is authenticated prior to decryption.

   If the authentication tag is included in the cipher text ciphertext placed in the
   security target block-type-specific data field, then this security
   result MUST NOT be included in the BCB for that security target.

   The length of the authentication tag, prior to any CBOR encoding,
   MUST be 128 bits.

   This value MUST be encoded as a CBOR byte string.

4.4.2.  Enumerations

   The BCB-AES-GCM security context results are listed in Table 6.  In
   this table, the "Result Id" column refers to the expected Result
   Identifier result
   identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter ("Parameter and Result Identification".

   BCB-AES-GCM Security Results
   Identification") of [RFC9172].

          +===========+====================+====================+
          | Result Id |    Result Name     | CBOR Encoding Type |
          +===========+====================+====================+
          |     1     | Authentication Tag |    Byte String    byte string     |
          +-----------+--------------------+--------------------+

                   Table 6 6: BCB-AES-GCM Security Results

4.5.  Key Considerations

   Keys used with this context MUST be symmetric and MUST have a key
   length equal to the key length defined in the security context
   parameters or as defined by local security policy at security
   verifiers and acceptors.  For this reason, content-encrypting key
   lengths will be integer integers divisible by 8 bytes bytes, and special padding-
   aware AES key wrap algorithms are not needed.

   It is assumed that any security verifier or security acceptor can
   determine the proper key to be used.  Potential sources of the key
   include (but are not limited to) the following.

   *  Pre-placed keys selected based on local policy.

   *  Keys extracted from material carried in the BCB.

   *  Session keys negotiated via a mechanism external to the BCB.

   When an AES-KW wrapped key is present in a security block, it is
   assumed that security verifiers and security acceptors can
   independently determine the key encryption key (KEK) KEK used in the wrapping of the symmetric
   AES content-encrypting key.

   The security provided by block ciphers is reduced as more data is
   processed with the same key.  The total number of AES blocks
   processed with a single key for AES-GCM is recommended to be less
   than 2^64, as described in Appendix B of [AES-GCM].

   Additionally, there exist limits on the number of encryptions that
   can be performed with the same key.  The total number of invocations
   of the authenticated encryption function with a single key for AES-
   GCM is required to not exceed 2^32, as described in Section 8.3 of
   [AES-GCM].

   As discussed in Section 6 and emphasized here, it is strongly
   recommended that keys be protected once generated, both when they are
   stored and when they are transmitted.

4.6.  GCM Considerations

   The GCM cryptographic mode of AES has specific requirements that MUST
   be followed by implementers for the secure function of the BCB-AES-
   GCM security context.  While these requirements are well documented
   in [AES-GCM], some of them are repeated here for emphasis.

   *  With the exception of the AES-KW function, the IVs used by the
      BCB-AES-GCM security context are considered to be per-invocation
      IVs.  The pairing of a per-invocation IV and a security key MUST
      be unique.  A per-invocation IV MUST NOT be used with a security
      key more than one time.  If a per-invocation IV and key pair are
      repeated
      repeated, then the GCM implementation is vulnerable to forgery
      attacks.  Because the loss of integrity protection occurs with
      even a single reuse, this situation is often considered to have
      catastrophic security consequences.  More information regarding
      the importance of the uniqueness of the IV value can be found in
      Appendix A of [AES-GCM].

      Methods of generating unique IV values are provided in Chapter Section 8
      of [AES-GCM].  For example, one method decomposes the IV value
      into a fixed field and an invocation field.  The fixed field being is a
      constant value associated with a device device, and the invocation field
      changing
      changes on each invocation (such as by incrementing an integer
      counter).  Implementers SHOULD carefully read all relevant
      sections of [AES-GCM] when generating any mechanism to create
      unique IVs.

   *  The AES-KW function used to wrap keys for the security contexts in
      this document uses a single, globally constant IV input to the AES
      cipher operation and, thus, and thus is distinct from the aforementioned
      requirement related to per-invocation IVs.

   *  While any tag-based authentication mechanism has some likelihood
      of being forged, this probability is increased when using AES-GCM.
      In particular, short tag lengths combined with very long messages
      SHOULD be avoided when using this mode.  The BCB-AES-GCM security
      context requires the use of 128-bit authentication tags at all
      times.  Concerns relating to the size of authentication tags is
      discussed in Appendices B and C of [AES-GCM].

   *  As discussed in Appendix B of [AES-GCM], implementations SHOULD
      limit the number of unsuccessful verification attempts for each
      key to reduce the likelihood of guessing tag values.  This type of
      check has potential state-keeping issues when AES-KW is used,
      since an attacker could cause a large number of keys to have been be used at
      least once.

   *  As discussed in the Security Considerations section Section 8 ("Security Considerations") of
      [I-D.ietf-dtn-bpsec],
      [RFC9172], delay-tolerant networks have a higher occurrence of
      replay attacks due to the store-and-forward nature of the network.
      Because GCM has no inherent replay attack protection, implementors
      SHOULD attempt to detect replay attacks by using mechanisms such
      as those described in Appendix D of [AES-GCM].

4.7.  Canonicalization Algorithms

   This section defines the canonicalization algorithms used to prepare
   the inputs used to generate both the cipher text ciphertext and the
   authentication tag.

   In all cases, the canonical form of any portion of an extension block
   MUST be performed created as described in [I-D.ietf-dtn-bpsec]. [RFC9172].  The canonicalization
   algorithms defined in [I-D.ietf-dtn-bpsec] [RFC9172] adhere to the canonical forms for
   extension blocks defined in
   [I-D.ietf-dtn-bpbis] [RFC9171] but resolve ambiguities related
   to how values are represented in CBOR.

4.7.1.  Cipher text related calculations  Calculations Related to Ciphertext

   The BCB operates over the block-type-specific data of a block, but
   the BP always encodes these data within a single, definite-length
   CBOR byte string.  Therefore, the plain text plaintext used during encryption
   MUST be calculated as the value of the block-type-specific data field
   of the security target excluding the BP CBOR encoding.

   Consider the following

   Table 7 shows two CBOR encoded CBOR-encoded examples and the plain text plaintext that would
   be extracted from them.  The first example is an unsigned integer,
   while the second is a byte string.

   CBOR Plain Text Extraction Examples

    +==============================+=======+==========================+
    |     CBOR Encoding (Hex)      |  CBOR |  Plain Text   Plaintext Part (Hex)   |
    |                              |  Part |                          |
    |                              | (Hex) |                          |
    +==============================+=======+==========================+
    |             18ED             |   18  |            ED            |
    +------------------------------+-------+--------------------------+
    | C24CDEADBEEFDEADBEEFDEADBEEF |  C24C | DEADBEEFDEADBEEFDEADBEEF |
    +------------------------------+-------+--------------------------+

                Table 7

   Similarly, the cipher text 7: CBOR Plaintext Extraction Examples

   The ciphertext used during decryption MUST be calculated as the
   single, definite-length CBOR byte string representing the
   block-type-specific block-type-
   specific data field excluding the CBOR byte string identifying byte
   and optional CBOR byte string length field.

   All other fields of the security target (such as the block type code,
   block number, block processing control flags, or any CRC information)
   MUST NOT be considered as part of encryption or decryption.

4.7.2.  Additional Authenticated Data

   The construction of additional authenticated data depends on the AAD
   scope flags that can be provided as part of customizing the behavior
   of this security context.

   The canonical form of the AAD input to the BCB-AES-GCM mechanism is
   constructed using the following process.  While the AAD scope flags
   might not be included in the BCB representing the security operation,
   they MUST be included in the AAD value itself.  This process MUST be
   followed when generating AAD for either encryption or decryption.

   1.  The canonical form of the AAD starts as the CBOR encoding of the
       AAD scope flags in which all unset flags, reserved bits, and
       unassigned bits have been set to 0.  For example, if the primary
       block flag, target header flag, and security header flag are each
       set, then the initial value of the canonical form of the AAD will
       be 0x07.

   2.  If the primary block flag of the AAD scope flags is set to 1,
       then a canonical form of the bundle's primary block MUST be
       calculated and the result appended to the AAD.

   3.  If the target header flag of the AAD scope flags is set to 1,
       then the canonical form of the block type code, block number, and
       block processing control flags associated with the security
       target MUST be calculated and, in that order, appended to the
       AAD.

   4.  If the security header flag of the AAD scope flags is set to 1,
       then the canonical form of the block type code, block number, and
       block processing control flags associated with the BIB MUST be
       calculated and, in that order, appended to the AAD.

4.8.  Processing

4.8.1.  Encryption

   During encryption, four inputs data elements are prepared for input to the AES/GCM
   AES-GCM cipher: the encryption key, the IV, the security target plain text
   plaintext to be encrypted, and any additional authenticated data.
   These data items MUST be generated as follows.

   Prior to encryption, if a CRC value is present for the target block,
   then that CRC value MUST be removed.  This requires removing the CRC
   field from the target block and setting the CRC type field of the
   target block to "no CRC is present."

   *  The encryption key MUST have the appropriate length as required by
      local security policy.  The key might be generated specifically
      for this encryption, given as part of local security policy, or
      obtained through some other key management mechanism as discussed
      in Section 4.5.

   *  The IV selected MUST be of the appropriate length.  Because
      replaying an IV in counter mode voids the confidentiality of all
      messages encrypted with said IV, this context also requires a
      unique IV for every encryption performed with the same key.  This
      means the same key and IV combination MUST NOT be used more than
      once.

   *  The security target plain text plaintext for encryption MUST be generated as
      discussed in Section 4.7.1.

   *  Additional authenticated data MUST be generated as discussed in
      Section 4.7.2 4.7.2, with the value of AAD scope flags being taken from
      local security policy.

   Upon successful encryption encryption, the following actions MUST occur.

   *  The cipher text ciphertext produced by AES/GCM AES-GCM MUST replace the bytes used to
      define the plain text plaintext in the security target block's block-type-
      specific data field.  The block length of the security target MUST
      be updated if the generated cipher text ciphertext is larger than the plain
      text
      plaintext (which can occur when the authentication tag is included
      in the cipher text ciphertext calculation, as discussed in Section 4.4).

   *  The authentication tag calculated by the AES/GCM AES-GCM cipher MAY be
      added as a security result for the security target in the BCB
      holding results for this security operation, in which case it MUST
      be processed as described in Section 4.4.

   *  The authentication tag MUST be included either as a security
      result in the BCB representing the security operation or (with the
      cipher text)
      ciphertext) in the security target block-type-specific data field.

   Finally, the BCB containing information about this security operation
   MUST be updated as follows.  These operations can occur in any order.

   *  The security context identifier for the BCB MUST be set to the
      context identifier for BCB-AES-GCM.

   *  The IV input to the cipher MUST be added as the IV security
      context parameter for the BCB.

   *  Any local flags used to generated generate AAD for this cipher MUST be
      placed in the AAD scope flags security context parameter for the
      BCB unless these flags are expected to be correctly configured at
      security verifiers and security acceptors in the network.

   *  The encryption key MAY be included as a security parameter context
      parameter, in which case it MUST be wrapped using the NIST AES-KW algorithm AES key wrap
      function as defined in [RFC3394] and the results of the wrapping
      added as the wrapped key security context parameter for the BCB.

   *  The AES variant used by this security context SHOULD be added as
      the AES variant security context parameter for the BCB if it
      differs from the default key length.  Otherwise, this parameter
      MAY be omitted if doing so provides a useful reduction in message
      sizes.

   Problems encountered in the encryption MUST be processed in
   accordance with local security policy.  This MAY include restoring a
   CRC value removed from the target block prior to encryption, if the
   target block is allowed to be transmitted after an encryption error.

4.8.2.  Decryption

   During decryption, five inputs data elements are prepared for input to the AES/GCM
   AES-GCM cipher: the decryption key, the IV, the security target cipher text
   ciphertext to be decrypted, any additional authenticated data, and
   the authentication tag generated from the original encryption.  These
   data items MUST be generated as follows.

   *  The decryption key MUST be derived using the wrapped key security
      context parameter if such a parameter is included in the security
      context parameters of the BCB.  Otherwise  Otherwise, this key MUST be
      derived in accordance with local security policy at the decrypting
      node as discussed in Section 4.5.

   *  The IV MUST be set to the value of the IV security context
      parameter included in the BCB.  If the IV parameter is not
      included as a security context parameter, an IV MAY be derived as
      a function of local security policy and other BCB contents contents, or a
      lack of an IV security context parameter in the BCB MAY be treated
      as an error by the decrypting node.

   *  The security target cipher text ciphertext for decryption MUST be generated as
      discussed in Section 4.7.1.

   *  Additional authenticated data MUST be generated as discussed in
      Section 4.7.2 with the value of AAD scope flags being taken from
      the AAD scope flags security context parameter.  If the AAD scope
      flags parameter is not included in the security context parameters
      parameters, then these flags MAY be derived from local security
      policy in cases where the set of such flags is determinable in the
      network.

   *  The authentication tag MUST be present either as a security result
      in the BCB representing the security operation or (with the cipher
      text)
      ciphertext) in the security target block-type-specific data field.

   Upon successful decryption decryption, the following actions action MUST occur.

   *  The plain text plaintext produced by AES/GCM AES-GCM MUST replace the bytes used to
      define the cipher text ciphertext in the security target block's block-type-
      specific data field.  Any changes to the security target block
      length field MUST be corrected in cases where the plain text plaintext has a
      different length than the replaced cipher text. ciphertext.

   If the security acceptor is not the bundle destination and if no
   other integrity or confidentiality service is being applied to the
   target block, then a CRC MUST be included for the target block.  The
   CRC type, as determined by policy, is set in the target block's CRC
   type field and the corresponding CRC value is added as the CRC field
   for that block.

   If the cipher text ciphertext fails to authenticate, if any needed parameters are
   missing, or if there are other problems in the decryption decryption, then the
   decryption MUST be treated as failed and processed in accordance with
   local security policy.

5.  IANA Considerations

5.1.  Security Context Identifiers

   This specification allocates two security context identifiers from
   the "BPSec Security Context Identifiers" registry defined in
   [I-D.ietf-dtn-bpsec].

   Additional Entries for the BPSec Security Context Identifiers
   Registry:

                 +=======+===============+===============+
   [RFC9172].

                   +=======+===============+===========+
                   | Value | Description   | Reference |
                 +=======+===============+===============+
                   +=======+===============+===========+
                   |  TBA   1   | BIB-HMAC-SHA2 | This document RFC 9173  |
                 +-------+---------------+---------------+
                   +-------+---------------+-----------+
                   |  TBA   2   | BCB-AES-GCM   | This document RFC 9173  |
                 +-------+---------------+---------------+
                   +-------+---------------+-----------+

                      Table 8 8: Additional Entries for
                         the BPSec Security Context
                            Identifiers Registry

5.2.  Integrity Scope Flags

   The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field
   for which IANA is requested to create has created and maintain now maintains a new registry named
   "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the Bundle
   Protocol "Bundle Protocol"
   registry page.  Initial  Table 9 shows the initial values for this registry are given
   below. registry.

   The registration policy for this registry is: is Specification Required. Required
   [RFC8126].

   The value range is unsigned 16-bit integer.

   BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry

   +==============================+=======================+===========+

      +==============================+==================+===========+
      | Bit Position (right to left) | Description      | Reference |
   +==============================+=======================+===========+
      +==============================+==================+===========+
      |              0               | Include primary block  |    This RFC 9173  |
      |                              | block flag       |  document           |
   +------------------------------+-----------------------+-----------+
      +------------------------------+------------------+-----------+
      |              1               | Include target header   |    This RFC 9173  |
      |                              | header flag      |  document           |
   +------------------------------+-----------------------+-----------+
      +------------------------------+------------------+-----------+
      |              2               | Include security |    This RFC 9173  |
      |                              | header flag      |  document           |
   +------------------------------+-----------------------+-----------+
      +------------------------------+------------------+-----------+
      |             3-7              |        reserved       |    This   |
   |                              | Reserved         |  document RFC 9173  |
   +------------------------------+-----------------------+-----------+
      +------------------------------+------------------+-----------+
      |             8-15             |       unassigned      |    This   |
   | Unassigned       |           |  document |
   +------------------------------+-----------------------+-----------+
      +------------------------------+------------------+-----------+

        Table 9 9: BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry

5.3.  AAD Scope Flags

   The BCB-AES-GCM security context has an AAD Scope Flags field for
   which IANA is requested to create has created and maintain now maintains a new registry named "BPSec
   BCB-AES-GCM AAD Scope Flags" on the Bundle Protocol "Bundle Protocol" registry page.  Initial
   Table 10 shows the initial values for this registry are given below. registry.

   The registration policy for this registry is: is Specification Required.

   The value range is unsigned 16-bit integer.

   BPSec BCB-AES-GCM AAD Scope Flags Registry

   +==============================+=======================+===========+

      +==============================+==================+===========+
      | Bit Position (right to left) | Description      | Reference |
   +==============================+=======================+===========+
      +==============================+==================+===========+
      |              0               | Include primary block  |    This RFC 9173  |
      |                              | block flag       |  document           |
   +------------------------------+-----------------------+-----------+
      +------------------------------+------------------+-----------+
      |              1               | Include target header   |    This RFC 9173  |
      |                              | header flag      |  document           |
   +------------------------------+-----------------------+-----------+
      +------------------------------+------------------+-----------+
      |              2               | Include security |    This RFC 9173  |
      |                              | header flag      |  document           |
   +------------------------------+-----------------------+-----------+
      +------------------------------+------------------+-----------+
      |             3-7              |        reserved       |    This   |
   | Reserved         | RFC 9173  |  document |
   +------------------------------+-----------------------+-----------+
      +------------------------------+------------------+-----------+
      |             8-15             |       unassigned      |    This   | Unassigned       |           |                       |  document |
   +------------------------------+-----------------------+-----------+
      +------------------------------+------------------+-----------+

            Table 10 10: BPSec BCB-AES-GCM AAD Scope Flags Registry

5.4.  Guidance for Designated Experts

   New assignments within the "BPSec BIB-HMAC-SHA2 Integrity Scope Flags
   Registry
   Flags" and the "BPSec BCB-AES-GCM AAD Scope Flags Registry Flags" registries require
   review by a Designated Expert (DE).  This section provides guidance
   to the DE when performing their reviews.  Specifically, a DE is
   expected to perform the following activities.

   *  Ascertain the existence of suitable documentation (a
      specification) as described in [RFC8126] and to verify that the
      document is permanently and publicly available.

   *  Ensure that any changes to the "BPSec BIB-HMAC-SHA2 Integrity
      Scope Flags Flags" registry clearly state how new assignments interact
      with existing flags and how the inclusion of new assignments
      affects the construction of the IPPT value.

   *  Ensure that any changes to the "BPSec BCB-AES-GCM AAD Scope Flags Flags"
      registry clearly state how new assignments interact with existing
      flags and how the inclusion of new assignments affects the
      construction of the AAD input to the BCB-AES-GCM mechanism.

   *  Ensure that any processing changes proposed with new assignments
      do not alter any required behavior in this specification.

6.  Security Considerations

   Security considerations specific to a single security context are
   provided in the description of that context. context (see Sections 3 and 4).
   This section discusses security considerations that should be
   evaluated by implementers of any security context described in this
   document.  Considerations can also be found in documents listed as
   normative references and they should also be reviewed by security context
   implementors.

6.1.  Key Management

   The delayed and disrupted nature of DTNs Delay-Tolerant Networking (DTN)
   complicates the process of key management because there might not be
   reliable, timely timely, round-trip exchange between security sources,
   security verifiers, and security acceptors in the network.  This is
   true when there is a substantial signal propagation delay between
   nodes, when nodes are in a highly challenged communications
   environment, and when nodes do not support
   bi-directional bidirectional
   communication.

   In these environments, key establishment protocols that rely on
   round-trip information exchange might not converge on a shared secret
   in a timely manner (or at all).  Also, key revocation or key
   verification mechanisms that rely on access to a centralized
   authority (such as a certificate authority) might similarly fail in
   the stressing conditions of a DTN.

   For these reasons, the default security contexts described in this
   document rely on symmetric key symmetric-key cryptographic mechanisms because
   asymmetric key
   asymmetric-key infrastructure (such as a public key infrastructure)
   might be impractical in this environment.

   BPSec assumes that "key management is handled as a separate part of
   network management" [I-D.ietf-dtn-bpsec]. [RFC9172].  This assumption is also made by the
   security contexts defined in this document document, which do not define new
   protocols for key derivation, exchange of key-encrypting
   keys, KEKs, revocation of
   existing keys, or the security configuration or policy used to select
   certain keys for certain security operations.

   Nodes using these security contexts need to perform the following
   kinds of activities, independent of the construction, transmission,
   and processing of BPSec security blocks.

   *  Establish shared key-encrypting-keys KEKs with other nodes in the network using an
      out-of-band mechanism.  This might include pre-
      sharing pre-sharing of key encryption keys KEKs or
      the use of traditional older key establishment mechanisms prior to the
      exchange of BPsec BPSec security blocks.

   *  Determine when a key is considered exhausted and no longer to be
      used in the generation, verification, or acceptance of a security
      block.

   *  Determine when a key is considered invalid and no longer to be
      used in the generation, verification, or acceptance of a security
      block.  Such revocations can be based on a variety of mechanisms
      to include mechanisms,
      including local security policy, time relative to the generation
      or use of the key, or as other mechanisms specified through network
      management.

   *  Determine, through an out-of-band mechanism such as local security
      policy, what keys are to be used for what security blocks.  This
      includes the selection of which key should be used in the
      evaluation of a security block received by a security verifier or
      a security acceptor.

   The failure to provide effective key management techniques
   appropriate for the operational networking environment can result in
   the compromise of those unmanaged keys and the loss of security
   services in the network.

6.2.  Key Handling

   Once generated, keys should be handled as follows.

   *  It is strongly RECOMMENDED that implementations protect keys both
      when they are stored and when they are transmitted.

   *  In the event that a key is compromised, any security operations
      using a security context associated with that key SHOULD also be
      considered compromised.  This means that the BIB-HMAC-SHA2
      security context SHOULD NOT be treated as providing integrity when
      used with a compromised key key, and BCB-AES-GCM SHOULD NOT be treated
      as providing confidentiality when used with a compromised key.

   *  The same key, whether a key-encrypting-key KEK or a wrapped key, MUST NOT be used for
      different algorithms as doing so might leak information about the
      key.

   *  A key-encrypting-key KEK MUST NOT be used to encrypt keys for different security
      contexts.  Any key-encrypting-key KEK used by a security context defined in this
      document MUST only be used to wrap keys associated with security
      operations using that security context.  This means that a
      compliant security source would not use the same key-encrypting-key KEK to wrap keys
      for both the BIB-
      HMAC-SHA2 BIB-HMAC-SHA2 and BCB-AES-GCM security contexts.
      Similarly, any compliant security verifier or security acceptor
      would not use the same key-encrypting-key KEK to unwrap keys for different security
      contexts.

6.3.  AES GCM

   There are a significant number of considerations related to the use
   of the GCM mode of AES to provide a confidentiality service.  These
   considerations are provided in Section 4.6 as part of the
   documentation of the BCB-AES-GCM security context.

   The length of the cipher text ciphertext produced by the GCM mode of AES will be
   equal to the length of the plain text plaintext input to the cipher suite.  The
   authentication tag also produced by this cipher suite is separate
   from the cipher text. ciphertext.  However, it should be noted that
   implementations of the AES-GCM cipher suite might not separate the
   concept of cipher text ciphertext and authentication tag in their application
   programming interface Application
   Programming Interface (API).

   Implementations of the BCB-AES-GCM security context can either keep
   the length of the target block unchanged by holding the
   authentication tag in a BCB security result or alter the length of
   the target block by including the authentication tag with the cipher
   text
   ciphertext replacing the block-type-specific-data block-type-specific data field of the target
   block.  Implementations MAY use the authentication tag security
   result in cases where keeping target block length unchanged is an
   important processing concern.  In all cases, the cipher text ciphertext and
   authentication tag MUST be processed in accordance with the API of
   the AES-GCM cipher suites at the security source and security
   acceptor.

6.4.  AES Key Wrap

   The AES key wrap (AES-KW) AES-KW algorithm used by the security contexts in this document
   does not use a per-invocation initialization vector and does not
   require any key padding.  Key padding is not needed because wrapped
   keys used by these security contexts will always be multiples of 8
   bytes.  The length of the wrapped key can be determined by inspecting
   the security context parameters.  Therefore, a key can be unwrapped
   using only the information present in the security block and the key encryption key KEK
   provided by local security policy at the security verifier or
   security acceptor.

6.5.  Bundle Fragmentation

   Bundle fragmentation might prevent security services in a bundle from
   being verified after a bundle is fragmented and before the bundle is
   re-assembled.  Examples of potential issues include the following.

   *  If a security block and its security target do not exist in the
      same fragment, then the security block cannot be processed until
      the bundle is re-assembled.  If a fragment includes an encrypted
      target block, but not its BCB, then a receiving bundle processing
      agent Bundle Protocol
      Agent (BPA) will not know that the target block has been
      encrypted.

   *  A security block can be cryptographically bound to a bundle by
      setting the Integrity Scope Flags integrity scope flags (for BIB-HMAC-SHA2) or the AAD
      Scope Flags
      scope flags (for BCB-AES-GCM) to include the bundle primary block.
      When a security block is cryptographically bound to a bundle, it
      cannot be processed even if the security block and target both
      coexist in the fragment.  This is because fragments have different
      primary blocks than the original bundle.

   *  If security blocks and their target blocks are repeated in
      multiple fragments, policy needs to determine how to deal with
      issues where a security operation verifies in one fragment but
      fails in another fragment.  This might happen, for example, if a
      BIB block becomes corrupted in one fragment but not in another
      fragment.

   Implementors should consider how security blocks are processed when a
   BPA fragments a received bundle.  For example, security blocks and
   their targets could be placed in the same fragment if the security
   block is not otherwise cryptographically bound to the bundle being
   fragmented.  Alternatively, if security blocks are cryptographically
   bound to a bundle, then a fragmenting BPA should consider
   encapsulating the bundle first and then fragmenting the encapsulating
   bundle.

7.  Normative References

   [AES-GCM]  Dworkin, M., "NIST Special Publication 800-38D:
              Recommendation "Recommendation for Block Cipher Modes of
              Operation: Galois/Counter Mode (GCM) and GMAC.", GMAC", NIST
              Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D,
              November 2007.

   [I-D.ietf-dtn-bpbis]
              Burleigh, S., Fall, K., and E. J. Birrane, "Bundle
              Protocol Version 7", Work in Progress, Internet-Draft,
              draft-ietf-dtn-bpbis-31, 25 January 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
              bpbis-31>.

   [I-D.ietf-dtn-bpsec]
              III, E. J. B. and K. McKeever, "Bundle Protocol Security
              Specification", Work in Progress, Internet-Draft, draft-
              ietf-dtn-bpsec-27, 16 February 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
              bpsec-27>. 2007, <https://doi.org/10.6028/NIST.SP.800-38D>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5649]  Housley, R.

   [RFC3394]  Schaad, J. and M. Dworkin, R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap with Padding Algorithm", RFC 5649, 3394, DOI 10.17487/RFC5649, 10.17487/RFC3394,
              September 2009,
              <https://www.rfc-editor.org/info/rfc5649>. 2002, <https://www.rfc-editor.org/info/rfc3394>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
              Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
              <https://www.rfc-editor.org/info/rfc8742>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

   [RFC9171]  Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
              Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
              January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.

   [RFC9172]  Birrane, III, E. and K. McKeever, "Bundle Protocol
              Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
              2022, <https://www.rfc-editor.org/rfc/rfc9172>.

   [SHS]      US NIST,      National Institute of Standards and Technology, "Secure
              Hash Standard (SHS).", FIPS- (SHS)", FIPS PUB 180-4, Gaithersburg, MD, USA,
              DOI 10.6028/NIST.FIPS.180-4, August 2015.
              https://csrc.nist.gov/publications/detail/fips/180/4/final 2015,
              <https://csrc.nist.gov/publications/detail/fips/180/4/
              final>.

Appendix A.  Examples

   This appendix is informative.

   This section appendix presents a series of examples of constructing BPSec
   security blocks (using the security contexts defined in this
   document) and adding those blocks to a sample bundle.

   The examples presented in this appendix represent valid constructions
   of bundles, security blocks, and the encoding of security context
   parameters and results.  For this reason, they can inform unit test
   suites for individual implementations as well as interoperability
   test suites amongst implementations.  However, these examples do not
   cover every permutation of security context parameters, security
   results, or use of security blocks in a bundle.

   NOTE:

   NOTES:

   *  The bundle diagrams in this section appendix are patterned after the
      bundle diagrams used in [I-D.ietf-dtn-bpsec] Section 3.11 "BSP ("BPSec Block
   Examples".

   NOTE: Examples") of
      [RFC9172].

   *  Figures in this section appendix identified as "(CBOR Diagnostic
      Notation)" are represented using the CBOR diagnostic notation
      defined in [RFC8949].  This notation is used to express CBOR data
      structures in a manner that enables visual inspection.  The
      bundles, security blocks, and security context contents in these
      figures are represented using CBOR structures.  In cases where BP
      blocks (to include BPSec security blocks) are comprised of a
      sequence of CBOR objects, these objects are represented as a CBOR
      sequence as defined in [RFC8742].

   NOTE:

   *  Examples in this section appendix use the "ipn" URI scheme for
   EndpointID endpoint ID
      naming, as defined in [I-D.ietf-dtn-bpbis].

   NOTE: [RFC9171].

   *  The bundle source is presumed to be the security source for all
      security blocks in this section, appendix, unless otherwise noted.

A.1.  Example 1: 1 - Simple Integrity

   This example shows the addition of a BIB to a sample bundle to
   provide integrity for the payload block.

A.1.1.  Original Bundle

   The following diagram shows the original bundle before the BIB has
   been added.

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Payload Block                         |   1   |    1   |
        +----------------------------------------+-------+--------+

                   Figure 1: Example 1 - Original Bundle

A.1.1.1.  Primary Block

   The BPv7 Bundle Protocol version 7 (BPv7) bundle has no special block and
   bundle processing flags control flags, and no CRC is provided because the
   primary block is expected to be protected by an integrity service BIB
   using the BIB-HMAC-SHA2 security context.

   The bundle is sourced at the source node ipn:2.1 and destined for the
   destination node ipn:1.2.  The bundle creation time uses a DTN
   creation time of 0 is set to 0,
   indicating lack of an accurate clock and clock, with a sequence number of 40.
   The lifetime of the bundle is given as 1,000,000 milliseconds since
   the bundle creation time.

   The primary block is provided as follows.

   [
     7,           / BP version            /
     0,           / flags                 /
     0,           / CRC type              /
     [2, [1,2]],  / destination (ipn:1.2) /
     [2, [2,1]],  / source      (ipn:2.1) /
     [2, [2,1]],  / report-to   (ipn:2.1) /
     [0, 40],     / timestamp             /
     1000000      / lifetime              /
   ]

             Figure 2: Primary Block (CBOR Diagnostic Notation)

   The CBOR encoding of the primary block is
   0x88070000820282010282028202018202820201820018281a000f4240. is:

   0x88070000820282010282028202018202820201820018281a000f4240

A.1.1.2.  Payload Block

   Other than its use as a source of plaintext for security blocks, the
   payload has no required distinguishing characteristic for the purpose
   of this example.  The sample payload is a 32 byte string whose value
   is "Ready Generate a 32 byte payload". 35-byte string.

   The payload is represented in the payload block as a byte string of
   the raw payload string.  It is NOT represented as a CBOR text string
   wrapped within a CBOR binary string.  The hex value of the payload
   "Ready Generate a 32 byte payload" is
   0x52656164792047656e657261746520612033322062797465207061796c6f6164.
   is:

   0x526561647920746f2067656e657261746520612033322d62797465207061796c6f
   6164

   The payload block is provided as follows.

   [
     1,                       / type code: Payload block       /
     1,                       / block number                   /
     0,                       / block processing control flags /
     0,                       / CRC Type type                       /
     h'52656164792047656e65726174652061
     h'526561647920746f206765 / type-specific-data: payload    /
       2033322062797465207061796c6f6164'
     6e657261746520612033322d
     62797465207061796c6f6164'
   ]

             Figure 3: Payload Block (CBOR Diagnostic Notation)

   The CBOR encoding of the payload block is 0x8501010000582052656164792
   047656e657261746520612033322062797465207061796c6f6164. is:

   0x85010100005823526561647920746f2067656e657261746520612033322d627974
   65207061796c6f6164

A.1.1.3.  Bundle CBOR Representation

   A BPv7 bundle is represented as an indefinite-length array consisting
   of the blocks comprising the bundle, with a terminator character at
   the end.

   The CBOR encoding of the original bundle is 0x9f880700008202820102820
   28202018202820201820018281a000f42408501010000582052656164792047656e65
   7261746520612033322062797465207061796c6f6164ff. is:

   0x9f88070000820282010282028202018202820201820018281a000f424085010100
   005823526561647920746f2067656e657261746520612033322d6279746520706179
   6c6f6164ff

A.1.2.  Security Operation Overview

   This example adds a BIB to the bundle using the BIB-HMAC-SHA2
   security context to provide an integrity mechanism over the payload
   block.

   The following diagram shows the resulting bundle after the BIB is
   added.

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Bundle  Block Integrity Block                 |   11  |    2   |
        |  OP(bib-integrity, target=1)           |       |        |
        +----------------------------------------+-------+--------+
        |  Payload Block                         |   1   |    1   |
        +----------------------------------------+-------+--------+

                   Figure 4: Example 1 - Resulting Bundle

A.1.3.  Bundle  Block Integrity Block

   In this example, a BIB is used to carry an integrity signature over
   the payload block.

A.1.3.1.  Configuration, Parameters, and Results

   For this example, the following configuration and security context
   parameters are used to generate the security results indicated.

   This BIB has a single target and includes a single security result:
   the calculated signature over the payload block.

             Key         : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
             SHA Variant : HMAC 512/512
             Scope Flags : 0x00
             Payload Data: h'52656164792047656e65726174652061
                             2033322062797465207061796c6f6164' h'526561647920746f2067656e65726174
                             6520612033322d62797465207061796c
                             6f6164'
             IPPT        : h'005823526561647920746f2067656e65
                             7261746520612033322d627974652070
                             61796c6f6164'
             Signature   : h'0654d65992803252210e377d66d0a8dc
                             18a1e8a392269125ae9ac198a9a598be
                             4b83d5daa8be2f2d16769ec1c30cfc34
                             8e2205fba4b3be2b219074fdd5ea8ef0' h'3bdc69b3a34a2b5d3a8554368bd1e808
                             f606219d2a10a846eae3886ae4ecc83c
                             4ee550fdfb1cc636b904e2f1a73e303d
                             cd4b6ccece003e95e8164dcc89a156e1'

        Figure 5: Example 1: 1 - Configuration, Parameters, and Results

A.1.3.2.  Abstract Security Block

   The abstract security block structure of the BIB's block-type-
   specific-data
   specific data field for this application is as follows.

   [1],           / Security Target        - Payload block       /
   1,             / Security Context ID    - BIB-HMAC-SHA2       /
   1,             / Security Context Flags - Parameters Present  /
   [2,[2, 1]],    / Security Source        - ipn:2.1             /
   [              / Security Parameters    - 2 Parameters        /
      [1, 7],     / SHA Variant            - HMAC 512/512        /
      [3, 0x00]   / Scope Flags            - No Additional Scope /
   ],
   [              / Security Results: 1 Result                   /
     [            / Target 1 Results                             /
       [1, h'0654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598b
   e4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0'] h'3bdc69b3a34a2b5d3a8554368bd1e808         / MAC      /
             f606219d2a10a846eae3886ae4ecc83c
             4ee550fdfb1cc636b904e2f1a73e303d
             cd4b6ccece003e95e8164dcc89a156e1']
     ]
   ]

          Figure 6: Example 1: 1 - BIB Abstract Security Block (CBOR
                            Diagnostic Notation)

   The CBOR encoding of the BIB block-type-specific-data block-type-specific data field (the
   abstract security block) is 0x810101018202820201828201078203008182015
   8400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b
   83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0. is:

   0x810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a8554
   368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2f1a7
   3e303dcd4b6ccece003e95e8164dcc89a156e1

A.1.3.3.  Representations

   The complete BIB wrapping this abstract security block is as follows.

   [
     11, / type code    /
     2,  / block number /
     0,  / flags        /
     0,  / CRC type     /
  h'8101010182028202018282010782030081820158400654d65992803252210e377d66
  d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc34
  8e2205fba4b3be2b219074fdd5ea8ef0',
     h'810101018202820201828201078203008181820158403bdc69b3a34a
     2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550
     fdfb1cc636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1'
   ]

            Figure 7: Example 1: 1 - BIB (CBOR Diagnostic Notation)

   The CBOR encoding of the BIB block is 0x850b0200005855810101018202820
   2018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392
   269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2
   b219074fdd5ea8ef0. is:

   0x850b0200005856810101018202820201828201078203008181820158403bdc69b3
   a34a2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1c
   c636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1

A.1.4.  Final Bundle

   The CBOR encoding of the full output bundle, with the BIB: 0x9f880700
   00820282010282028202018202820201820018281a000f4240850b020000585581010
   10182028202018282010782030081820158400654d65992803252210e377d66d0a8dc
   18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e220
   5fba4b3be2b219074fdd5ea8ef08501010000582052656164792047656e6572617465
   20612033322062797465207061796c6f6164ff.

   0x9f88070000820282010282028202018202820201820018281a000f4240850b0200
   005856810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a
   8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2
   f1a73e303dcd4b6ccece003e95e8164dcc89a156e185010100005823526561647920
   746f2067656e657261746520612033322d62797465207061796c6f6164ff

A.2.  Example 2: 2 - Simple Confidentiality with Key Wrap

   This example shows the addition of a BCB to a sample bundle to
   provide confidentiality for the payload block.  AES key wrap is used
   to transmit the symmetric key used to generate the security results
   for this service.

A.2.1.  Original Bundle

   The following diagram shows the original bundle before the BCB has
   been added.

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Payload Block                         |   1   |    1   |
        +----------------------------------------+-------+--------+

                   Figure 8: Example 2 - Original Bundle

A.2.1.1.  Primary Block

   The primary block used in this example is identical to the primary
   block presented in for Example 1 in Appendix A.1.1.1.

   In summary, the CBOR encoding of the primary block is
   0x88070000820282010282028202018202820201820018281a000f4240. is:

   0x88070000820282010282028202018202820201820018281a000f4240

A.2.1.2.  Payload Block

   The payload block used in this example is identical to the payload
   block presented in for Example 1 in Appendix A.1.1.2.

   In summary, the CBOR encoding of the payload block is 0x8501010000582
   052656164792047656e657261746520612033322062797465207061796c6f6164. is:

   0x85010100005823526561647920746f2067656e657261746520612033322d627974
   65207061796c6f6164

A.2.1.3.  Bundle CBOR Representation

   A BPv7 bundle is represented as an indefinite-length array consisting
   of the blocks comprising the bundle, with a terminator character at
   the end.

   The CBOR encoding of the original bundle is 0x9f880700008202820102820
   28202018202820201820018281a000f42408501010000582052656164792047656e65
   7261746520612033322062797465207061796c6f6164ff. is:

   0x9f88070000820282010282028202018202820201820018281a000f424085010100
   005823526561647920746f2067656e657261746520612033322d6279746520706179
   6c6f6164ff

A.2.2.  Security Operation Overview

   This example adds a BCB using the BCB-AES-GCM security context using
   AES key wrap to provide a confidentiality mechanism over the payload
   block and transmit the symmetric key.

   The following diagram shows the resulting bundle after the BCB is
   added.

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Bundle  Block Confidentiality Block           |   12  |    2   |
        |  OP(bcb-confidentiality, target=1)     |       |        |
        +----------------------------------------+-------+--------+
        |  Payload Block (Encrypted)             |   1   |    1   |
        +----------------------------------------+-------+--------+

                   Figure 9: Example 2 - Resulting Bundle

A.2.3.  Bundle  Block Confidentiality Block

   In this example, a BCB is used to encrypt the payload block block, and uses AES
   key wrap is used to transmit encode the symmetric key. key prior to its inclusion
   in the BCB.

A.2.3.1.  Configuration, Parameters, and Results

   For this example, the following configuration and security context
   parameters are used to generate the security results indicated.

   This BCB has a single target, target -- the payload block.  Three security
   results are generated: cipher text which ciphertext that replaces the plain text
   block-type-specific plaintext block-
   type-specific data to encrypt the payload block, an authentication
   tag, and the AES wrapped key.

          Content Encryption
                         Key: h'71776572747975696f70617364666768'
          Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70'
                          IV: h'5477656c7665313231323132'
                 AES Variant: A128GCM
             AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892
                                96fabf34d7fae700'
                 Scope Flags: 0x00
                Payload Data: h'52656164792047656e65726174652061
                          2033322062797465207061796c6f6164' h'526561647920746f2067656e65726174
                                6520612033322d62797465207061796c
                                6f6164'
                         AAD: h'00'
          Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' h'efa4b5ac0108e3816c5606479801bc04'
          Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354
                          a563e32648b700c2784e26a990d91f9d' h'3a09c1e63fe23a7f66a59c7303837241
                                e070b02619fc59c5214a22f08cd70795
                                e73e9a'

       Figure 10: Example 2: 2 - Configuration, Parameters, and Results

A.2.3.2.  Abstract Security Block

   The abstract security block structure of the BCB's block-type-
   specific-data
   specific data field for this application is as follows.

   [1],               / Security Target        - Payload block       /
   2,                 / Security Context ID    - BCB-AES-GCM         /
   1,                 / Security Context Flags - Parameters Present  /
   [2,[2, 1]],        / Security Source        - ipn:2.1             /
   [                  / Security Parameters    - 4 Parameters        /
     [1, h'5477656c7665313231323132'], / Initialization Vector       /
     [2, 1],                           / AES Variant - A128GCM       /
     [3, h'69c411276fecddc4780df42c8a  / AES wrapped key             /
           2af89296fabf34d7fae700'],
     [4, 0x00]                         / Scope Flags - No extra scope/
   ],
   [                                   /  Security Results: 1 Result /
     [                                 /  Target 1 Results           /
       [1, h'da08f4d8936024ad7c6b3b800e73dd97'] h'efa4b5ac0108e3816c5606479801bc04']  / Payload Auth. Tag /
     ]
   ]

          Figure 11: Example 2: 2 - BCB Abstract Security Block (CBOR
                            Diagnostic Notation)

   The CBOR encoding of the BCB block-type-specific-data block-type-specific data field (the
   abstract security block) is 0x8101020182028202018482014c5477656c76653
   132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fa
   e70082040081820150da08f4d8936024ad7c6b3b800e73dd97. is:

   0x8101020182028202018482014c5477656c76653132313231328202018203581869
   c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150efa4b5
   ac0108e3816c5606479801bc04

A.2.3.3.  Representations

   The complete BCB wrapping this abstract security block is as follows.

   [
     12, / type code                                          /
     2,  / block number                                       /
     1,  / flags - block must be replicated in every fragment /
     0,  / CRC type                                           /
     h'8101020182028202018482014c5477656c766531323132313282020182035818
       69c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da
       08f4d8936024ad7c6b3b800e73dd97'
       69c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150
       efa4b5ac0108e3816c5606479801bc04'
   ]

           Figure 12: Example 2: 2 - BCB (CBOR Diagnostic Notation)

   The CBOR encoding of the BCB block is 0x850c020100584f810102018202820
   2018482014c5477656c76653132313231328202018203581869c411276fecddc4780d
   f42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e7
   3dd97. is:

   0x850c02010058508101020182028202018482014c5477656c766531323132313282
   02018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081
   81820150efa4b5ac0108e3816c5606479801bc04

A.2.4.  Final Bundle

   The CBOR encoding of the full output bundle, with the BCB: 0x9f880700
   00820282010282028202018202820201820018281a000f4240850c020100584f81010
   20182028202018482014c5477656c76653132313231328202018203581869c411276f
   ecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7
   c6b3b800e73dd97850101000058203a09c1e63fe2097528a78b7c12943354a563e326
   48b700c2784e26a990d91f9dff.

   0x9f88070000820282010282028202018202820201820018281a000f4240850c0201
   0058508101020182028202018482014c5477656c7665313231323132820201820358
   1869c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150ef
   a4b5ac0108e3816c5606479801bc04850101000058233a09c1e63fe23a7f66a59c73
   03837241e070b02619fc59c5214a22f08cd70795e73e9aff

A.3.  Example 3: 3 - Security Blocks from Multiple Sources

   This example shows the addition of a BIB and BCB to a sample bundle.
   These two security blocks are added by two different nodes.  The BCB
   is added by the source endpoint endpoint, and the BIB is added by a forwarding
   node.

   The resulting bundle contains a BCB to encrypt the Payload Block and
   a BIB to provide integrity to the Primary primary block and Bundle Age Block.

A.3.1.  Original Bundle

   The following diagram shows the original bundle before the security
   blocks have been added.

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Extension Block: Bundle Age Block     |   7   |    2   |
        +----------------------------------------+-------+--------+
        |  Payload Block                         |   1   |    1   |
        +----------------------------------------+-------+--------+

                   Figure 13: Example 3 - Original Bundle

A.3.1.1.  Primary Block

   The primary block used in this example is identical to the primary
   block presented in for Example 1 in Appendix A.1.1.1.

   In summary, the CBOR encoding of the primary block is
   0x88070000820282010282028202018202820201820018281a000f4240. is:

   0x88070000820282010282028202018202820201820018281a000f4240

A.3.1.2.  Bundle Age Block

   A bundle age block Bundle Age Block is added to the bundle to help other nodes in the
   network determine the age of the bundle.  The use of this block is as
   recommended because the bundle source does not have an accurate clock
   (as indicated by the DTN time of 0).

   Because this block is specified at the time the bundle is being
   forwarded, the bundle age represents the time that has elapsed from
   the time the bundle was created to the time it is being prepared for
   forwarding.  In this case, the value is given as 300 milliseconds.

   The bundle age Bundle Age extension block is provided as follows.

   [
     7,      / type code: Bundle Age block Block    /
     2,      / block number                   /
     0,      / block processing control flags /
     0,      / CRC Type type                       /
     <<300>> / type-specific-data: age        /
   ]

           Figure 14: Bundle Age Block (CBOR Diagnostic Notation)

   The CBOR encoding of the bundle age block is 0x85070200004319012c. Bundle Age Block is:

   0x85070200004319012c

A.3.1.3.  Payload Block

   The payload block used in this example is identical to the payload
   block presented in for Example 1 in Appendix A.1.1.2.

   In summary, the CBOR encoding of the payload block is 0x8501010000582
   052656164792047656e657261746520612033322062797465207061796c6f6164. is:

   0x85010100005823526561647920746f2067656e657261746520612033322d627974
   65207061796c6f6164

A.3.1.4.  Bundle CBOR Representation

   A BPv7 bundle is represented as an indefinite-length array consisting
   of the blocks comprising the bundle, with a terminator character at
   the end.

   The CBOR encoding of the original bundle is 0x9f880700008202820102820
   28202018202820201820018281a000f424085070200004319012c8501010000582052
   656164792047656e657261746520612033322062797465207061796c6f6164ff. is:

   0x9f88070000820282010282028202018202820201820018281a000f424085070200
   004319012c85010100005823526561647920746f2067656e65726174652061203332
   2d62797465207061796c6f6164ff

A.3.2.  Security Operation Overview

   This example provides:

   *  a BIB with the BIB-HMAC-SHA2 security context to provide an
      integrity mechanism over the primary block and bundle age block. Bundle Age Block.

   *  a BCB with the BCB-AES-GCM security context to provide a
      confidentiality mechanism over the payload block.

   The following diagram shows the resulting bundle after the security
   blocks are added.

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Bundle  Block Integrity Block                 |   11  |    3   |
        |  OP(bib-integrity, targets=0, 2)       |       |        |
        +----------------------------------------+-------+--------+
        |  Bundle  Block Confidentiality Block           |   12  |    4   |
        |  OP(bcb-confidentiality, target=1)     |       |        |
        +----------------------------------------+-------+--------+
        |  Extension Block: Bundle Age Block     |   7   |    2   |
        +----------------------------------------+-------+--------+
        |  Payload Block (Encrypted)             |   1   |    1   |
        +----------------------------------------+-------+--------+

                  Figure 15: Example 3 - Resulting Bundle

A.3.3.  Bundle  Block Integrity Block

   In this example, a BIB is used to carry an integrity signature over
   the bundle age block Bundle Age Block and an additional signature over the payload
   block.  The BIB is added by a waypoint node, node -- ipn:3.0.

A.3.3.1.  Configuration, Parameters, and Results

   For this example, the following configuration and security context
   parameters are used to generate the security results indicated.

   This BIB has two security targets and includes two security results,
   holding the calculated signatures over the bundle age block Bundle Age Block and
   primary block.

                         Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
                 SHA Variant: HMAC 256/256
                 Scope Flags: 0x00
          Primary Block Data: h'88070000820282010282028202018202
                                820201820018281a000f4240'
          Bundle Age Block
                        Data: h'85070200004319012c' h'4319012c'
          Primary Block IPPT: h'00581c88070000820282010282028202
                                018202820201820018281a000f4240'
         Bundle Age Block
                        IPPT: h'004319012c'
          Primary Block
                   Signature: h'8e059b8e71f7218264185a666bf3e453
                          076f2b883f4dce9b3cdb6464ed0dcf0f' h'cac6ce8e4c5dae57988b757e49a6dd14
                                31dc04763541b2845098265bc817241b'
          Bundle Age Block
                   Signature: h'72dee8eba049a22978e84a95d0496466
                          8eb131b1ca4800c114206d70d9065c80' h'3ed614c0d97f49b3633627779aa18a33
                                8d212bf3c92b97759d9739cd50725596'

     Figure 16: Example 3: 3 - Configuration, Parameters, and Results for
                                  the BIB

A.3.3.2.  Abstract Security Block

   The abstract security block structure of the BIB's block-type-
   specific-data
   specific data field for this application is as follows.

   [0, 2],         / Security Targets                             /
   1,              / Security Context ID    - BIB-HMAC-SHA2       /
   1,              / Security Context Flags - Parameters Present  /
   [2,[3, 0]],     / Security Source        - ipn:3.0             /
   [               / Security Parameters    - 2 Parameters        /
      [1, 5],      / SHA Variant            - HMAC 256/256 256            /
      [3, 0x00] 0]       / Scope Flags            - No Additional Scope /
   ],
   [               / Security Results: 2 Results                  /
      [1, h'8e059b8e71f7218264185a666bf3e453
            076f2b883f4dce9b3cdb6464ed0dcf0f'],
      [            / Primary Block Results                        /
          [1, h'72dee8eba049a22978e84a95d0496466
            8eb131b1ca4800c114206d70d9065c80'] h'cac6ce8e4c5dae57988b757e49a6dd14
                31dc04763541b2845098265bc817241b']       / MAC    /
       ],
       [           / Bundle Age Block Results                     /
          [1, h'3ed614c0d97f49b3633627779aa18a33
                8d212bf3c92b97759d9739cd50725596']       / MAC    /
       ]
   ]

          Figure 17: Example 3: 3 - BIB Abstract Security Block (CBOR
                            Diagnostic Notation)

   The CBOR encoding of the BIB block-type-specific-data block-type-specific data field (the
   abstract security block) is 0x820002010182028203008282010582030082820
   158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f
   8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065
   c80. is:

   0x8200020101820282030082820105820300828182015820cac6ce8e4c5dae57988b
   757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d97f49
   b3633627779aa18a338d212bf3c92b97759d9739cd50725596

A.3.3.3.  Representations

   The complete BIB wrapping this abstract security block is as follows.

   [
     11, / type code    /
     3,  / block number /
     0,  / flags        /
     0,  / CRC type     /
     h'820002010182028203008282010582030082820158208e059b8e71f721826418
       5a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049
       a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80',
     h'8200020101820282030082820105820300828182015820cac6ce8e4c5dae5798
     8b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9
     7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596'
   ]

           Figure 18: Example 3: 3 - BIB (CBOR Diagnostic Notation)

   The CBOR encoding of the BIB block is 0x850b030000585a820002010182028
   203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b88
   3f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb13
   1b1ca4800c114206d70d9065c80. is:

   0x850b030000585c8200020101820282030082820105820300828182015820cac6ce
   8e4c5dae57988b757e49a6dd1431dc04763541b2845098265bc817241b8182015820
   3ed614c0d97f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596

A.3.4.  Bundle  Block Confidentiality Block

   In this example, a BCB is used encrypt the payload block.  The BCB is
   added by the bundle source node, ipn:2.1.

A.3.4.1.  Configuration, Parameters, and Results

   For this example, the following configuration and security context
   parameters are used to generate the security results indicated.

   This BCB has a single target, the payload block.  Two security
   results are generated: cipher text which ciphertext that replaces the plain text
   block-type-specific plaintext block-
   type-specific data to encrypt the payload block, block and an authentication
   tag.

          Content Encryption
                         Key: h'71776572747975696f70617364666768'
                          IV: h'5477656c7665313231323132'
                 AES Variant: A128GCM
                 Scope Flags: 0x00
                Payload Data: h'52656164792047656e65726174652061
                          2033322062797465207061796c6f6164' h'526561647920746f2067656e65726174
                                6520612033322d62797465207061796c
                                6f6164'
                         AAD: h'00'
          Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' h'efa4b5ac0108e3816c5606479801bc04'
          Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354
                          a563e32648b700c2784e26a990d91f9d' h'3a09c1e63fe23a7f66a59c7303837241
                                e070b02619fc59c5214a22f08cd70795
                                e73e9a'

     Figure 19: Example 3: 3 - Configuration, Parameters, and Results for
                                  the BCB

A.3.4.2.  Abstract Security Block

   The abstract security block structure of the BCB's block-type-
   specific-data
   specific data field for this application is as follows.

   [1],             / Security Target        - Payload block      /
   2,               / Security Context ID    - BCB-AES-GCM        /
   1,               / Security Context Flags - Parameters Present /
   [2,[2, 1]],      / Security Source        - ipn:2.1            /
   [                / Security Parameters    - 3 Parameters       /
     [1, h'5477656c7665313231323132'],    / Initialization Vector /
     [2, 1],                              / AES Variant - AES 128 /
     [4, 0x00] 0]                   / Scope Flags - No Additional Scope /
   ],
   [                                 / Security Results: 1 Result /
     [
        [1, h'da08f4d8936024ad7c6b3b800e73dd97'] h'efa4b5ac0108e3816c5606479801bc04'] / Payload Auth. Tag /
     ]
   ]

          Figure 20: Example 3: 3 - BCB Abstract Security Block (CBOR
                            Diagnostic Notation)

   The CBOR encoding of the BCB block-type-specific-data block-type-specific data field (the
   abstract security block) is 0x8101020182028202018382014c5477656c76653
   1323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd97. is:

   0x8101020182028202018382014c5477656c76653132313231328202018204008181
   820150efa4b5ac0108e3816c5606479801bc04

A.3.4.3.  Representations

   The complete BCB wrapping this abstract security block is as follows.

   [
     12, / type code                                          /
     4,  / block number                                       /
     1,  / flags - block must be replicated in every fragment /
     0,  / CRC type                                           /
     h'8101020182028202018382014c5477656c766531323132313282020182040081
       820150da08f4d8936024ad7c6b3b800e73dd97',
       81820150efa4b5ac0108e3816c5606479801bc04'
   ]

           Figure 21: Example 3: 3 - BCB (CBOR Diagnostic Notation)

   The CBOR encoding of the BCB block is 0x850c0401005833810102018202820
   2018382014c5477656c766531323132313282020182040081820150da08f4d8936024
   ad7c6b3b800e73dd97. is:

   0x850c04010058348101020182028202018382014c5477656c766531323132313282
   02018204008181820150efa4b5ac0108e3816c5606479801bc04

A.3.5.  Final Bundle

   The CBOR encoding of the full output bundle, with the BIB and BCB
   added is: 0x9f88070000820282010282028202018202820201820018281a000f424
   0850b030000585a820002010182028203008282010582030082820158208e059b8e71
   f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8e
   ba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80850c04010058
   338101020182028202018382014c5477656c766531323132313282020182040081820
   150da08f4d8936024ad7c6b3b800e73dd9785070200004319012c850101000058203a
   09c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff.

   0x9f88070000820282010282028202018202820201820018281a000f4240850b0300
   00585c8200020101820282030082820105820300828182015820cac6ce8e4c5dae57
   988b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9
   7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596850c0401005834
   8101020182028202018382014c5477656c7665313231323132820201820400818182
   0150efa4b5ac0108e3816c5606479801bc0485070200004319012c85010100005823
   3a09c1e63fe23a7f66a59c7303837241e070b02619fc59c5214a22f08cd70795e73e
   9aff

A.4.  Example 4: 4 - Security Blocks with Full Scope

   This example shows the addition of a BIB and BCB to a sample bundle.
   A BIB is added to provide integrity over the payload block block, and a BCB
   is added for confidentiality over the payload and BIB.

   The integrity scope and additional authentication data will bind the
   primary block, target header, and the security header.

A.4.1.  Original Bundle

   The following diagram shows the original bundle before the security
   blocks have been added.

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Payload Block                         |   1   |    1   |
        +----------------------------------------+-------+--------+

                   Figure 22: Example 4 - Original Bundle

A.4.1.1.  Primary Block

   The primary block used in this example is identical to the primary
   block presented in for Example 1 in Appendix A.1.1.1.

   In summary, the CBOR encoding of the primary block is
   0x88070000820282010282028202018202820201820018281a000f4240. is:

   0x88070000820282010282028202018202820201820018281a000f4240

A.4.1.2.  Payload Block

   The payload block used in this example is identical to the payload
   block presented in for Example 1 in Appendix A.1.1.2.

   In summary, the CBOR encoding of the payload block is 0x8501010000582
   052656164792047656e657261746520612033322062797465207061796c6f6164. is:

   0x85010100005823526561647920746f2067656e657261746520612033322d627974
   65207061796c6f6164

A.4.1.3.  Bundle CBOR Representation

   A BPv7 bundle is represented as an indefinite-length array consisting
   of the blocks comprising the bundle, with a terminator character at
   the end.

   The CBOR encoding of the original bundle is 0x9f880700008202820102820
   28202018202820201820018281a000f42408501010000582052656164792047656e65
   7261746520612033322062797465207061796c6f6164ff. is:

   0x9f88070000820282010282028202018202820201820018281a000f424085010100
   005823526561647920746f2067656e657261746520612033322d6279746520706179
   6c6f6164ff

A.4.2.  Security Operation Overview

   This example provides:

   *  a BIB with the BIB-HMAC-SHA2 security context to provide an
      integrity mechanism over the payload block.

   *  a BCB with the BCB-AES-GCM security context to provide a
      confidentiality mechanism over the payload block and BIB.

   The following diagram shows the resulting bundle after the security
   blocks are added.

                          Block                    Block   Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                         |  N/A  |    0   |
        +----------------------------------------+-------+--------+
        |  Bundle  Block Integrity Block (Encrypted)     |   11  |    3   |
        |  OP(bib-integrity, target=1)           |       |        |
        +----------------------------------------+-------+--------+
        |  Bundle  Block Confidentiality Block           |   12  |    2   |
        |  OP(bcb-confidentiality, targets=1, 3) |       |        |
        +----------------------------------------+-------+--------+
        |  Payload Block (Encrypted)             |   1   |    1   |
        +----------------------------------------+-------+--------+

                  Figure 23: Example 4 - Resulting Bundle

A.4.3.  Bundle  Block Integrity Block

   In this example, a BIB is used to carry an integrity signature over
   the payload block.  The IPPT contains the block-type-specific data of
   the payload block block-type-
   specific data, block, the primary block data, the payload block header,
   and the BIB header.  That is, all additional headers are included in
   the IPPT.

A.4.3.1.  Configuration, Parameters, and Results

   For this example, the following configuration and security context
   parameters are used to generate the security results indicated.

   This BIB has a single target and includes a single security result:
   the calculated signature over the Payload block.

                         Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
                 SHA Variant: HMAC 384/384
                 Scope Flags: 0x07  (all additional headers)
          Primary Block Data: h'88070000820282010282028202018202
                                820201820018281a000f4240
                                820201820018281a000f4240'
                Payload Data: h'52656164792047656e65726174652061
                                2033322062797465207061796c6f6164' h'526561647920746f2067656e65726174
                                6520612033322d62797465207061796c
                                6f6164'
              Payload Header: h'85010100005820' h'010100'
                  BIB Header: h'850b0300005845' h'0b0300'
                        IPPT: h'07880700008202820102820282020182
                                02820201820018281a000f4240010100
                                0b03005823526561647920746f206765
                                6e657261746520612033322d62797465
                                207061796c6f6164'
           Payload Signature: h'07c84d929f83bee4690130729d77a1bd
                                da9611cd6598e73d0659073ea74e8c27
                                523b02193cb8ba64be58dbc556887aca h'f75fe4c37f76f046165855bd5ff72fbf
                                d4e3a64b4695c40e2b787da005ae819f
                                0a2e30a2e8b325527de8aefb52e73d71,

     Figure 24: Example 4: 4 - Configuration, Parameters, and Results for
                                  the BIB

A.4.3.2.  Abstract Security Block

   The abstract security block structure of the BIB's block-type-
   specific-data
   specific data field for this application is as follows.

   [1],           / Security Target          - Payload block          /
   1,             / Security Context ID      - BIB-HMAC-SHA2          /
   1,             / Security Context Flags   - Parameters Present     /
   [2,[2, 1]],    / Security Source          - ipn:2.1                /
   [              / Security Parameters      - 2 Parameters           /
      [1, 6],     / SHA Variant              - HMAC 384/384           /
      [3, 0x07]   / Scope Flags              - All additional headers in the SHA Hash /
   ],
   [              / Security Results: 1 Result                        /
     [            / Target 1 Results                                  /
       [1, h'07c84d929f83bee4690130729d77a1bdda9611cd6598e73d
          0659073ea74e8c27523b02193cb8ba64be58dbc556887aca'] h'f75fe4c37f76f046165855bd5ff72fbf         / MAC           /
             d4e3a64b4695c40e2b787da005ae819f
             0a2e30a2e8b325527de8aefb52e73d71']
     ]
   ]

          Figure 25: Example 4: 4 - BIB Abstract Security Block (CBOR
                            Diagnostic Notation)

   The CBOR encoding of the BIB block-type-specific-data block-type-specific data field (the
   abstract security block) is 0x810101018202820201828201068203078182015
   83007c84d929f83bee4690130729d77a1bdda9611cd6598e73d0659073ea74e8c2752
   3b02193cb8ba64be58dbc556887aca. is:

   0x81010101820282020182820106820307818182015830f75fe4c37f76f046165855
   bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8aefb52
   e73d71

A.4.3.3.  Representations

   The complete BIB wrapping this abstract security block is as follows.

   [
     11, / type code    /
     3,  / block number /
     0,  / flags        /
     0,  / CRC type     /
     h'81010101820282020182820106820307818201583007c84d929f83bee4690130
       729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58db
       c556887aca',
     h'81010101820282020182820106820307818182015830f75fe4c37f76f0461658
       55bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8
       aefb52e73d71'
   ]

           Figure 26: Example 4: 4 - BIB (CBOR Diagnostic Notation)

   The CBOR encoding of the BIB block is 0x850b0300005845810101018202820
   20182820106820307818201583007c84d929f83bee4690130729d77a1bdda9611cd65
   98e73d0659073ea74e8c27523b02193cb8ba64be58dbc556887aca. is:

   0x850b030000584681010101820282020182820106820307818182015830f75fe4c3
   7f76f046165855bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b3
   25527de8aefb52e73d71

A.4.4.  Bundle  Block Confidentiality Block

   In this example, a BCB is used encrypt the payload block and the BIB
   that provides integrity over the payload.

A.4.4.1.  Configuration, Parameters, and Results

   For this example, the following configuration and security context
   parameters are used to generate the security results indicated.

   This BCB has two targets: the payload block and BIB.  Four security
   results are generated: cipher text which ciphertext that replaces the plain text
   block-type-specific plaintext block-
   type-specific data of the payload block, cipher text ciphertext to encrypt the
   BIB, and authentication tags for both the payload block and BIB.

                         Key: h'71776572747975696f70617364666768
                                71776572747975696f70617364666768'
                          IV: h'5477656c7665313231323132'
                 AES Variant: A256GCM
                 Scope Flags: 0x07  (All additional headers)
                Payload Data: h'52656164792047656e65726174652061
                                2033322062797465207061796c6f6164' h'526561647920746f2067656e65726174
                                6520612033322d62797465207061796c
                                6f6164'
                    BIB Data: h'81010101820282020182820106820307
                                818201583007c84d929f83bee4690130
                                729d77a1bdda9611cd6598e73d065907
                                3ea74e8c27523b02193cb8ba64be58db
                                c556887aca
                                818182015830f75fe4c37f76f0461658
                                55bd5ff72fbfd4e3a64b4695c40e2b78
                                7da005ae819f0a2e30a2e8b325527de8
                                aefb52e73d71'
           Primary Block Data: h'88070000820282010282028202018202
                                 820201820018281a000f4240'
               Payload Header: h'010100'
                   BIB
          Authentication Tag: h'c95ed4534769b046d716e1cdfd00830e' Header: h'0b0300'
                   BCB Header: h'0c0201'
                  Payload AAD: h'07880700008202820102820282020182
                                 02820201820018281a000f4240010100
                                 0c0201'
                      BIB AAD: h'07880700008202820102820282020182
                                 02820201820018281a000f42400b0300
                                 0c0201'
               Payload Block
          Authentication Tag: h'0e365c700e4bb19c0d991faff5345aff' h'd2c51cb2481792dae8b21d848cede99b'
                         BIB
          Authentication Tag: h'220ffc45c8a901999ecc60991dd78b29'
          Payload Ciphertext: h'90eab64575930498d6aa654107f15e96
                                319bb227706000abc8fcac3b9bb9c87e' h'90eab6457593379298a8724e16e61f83
                                7488e127212b59ac91f8a86287b7d076
                                30a122'
              BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0
                                902a815f221ebc837a134efc13bfa82a
                                2d5d317747da3eb54acef4ca839bd961
                                487284404259b60be12b8aed2f3e8a36
                                2836529f66'
                                902902064a2983910c4fb2340790bf42
                                0a7d1921d5bf7c4721e02ab87a93ab1e
                                0b75cf62e4948727c8b5dae46ed2af05
                                439b88029191'

     Figure 27: Example 4: 4 - Configuration, Parameters, and Results for
                                  the BCB

A.4.4.2.  Abstract Security Block

   The abstract security block structure of the BCB's block-type-
   specific-data
   specific data field for this application is as follows.

   [3, 1],          / Security Targets                            /
   2,               / Security Context ID    - BCB-AES-GCM        /
   1,               / Security Context Flags - Parameters Present /
   [2,[2, 1]],      / Security Source        - ipn:2.1            /
   [                / Security Parameters    - 3 Parameters       /
     [1, h'5477656c7665313231323132'],    / Initialization Vector /
     [2, 3],                              / AES Variant - AES 256 /
     [4, 0x07]            / Scope Flags - All headers in SHA hash /
   ],
   [                                / Security Results: 2 Results /
     [
        [1, h'c95ed4534769b046d716e1cdfd00830e'], h'220ffc45c8a901999ecc60991dd78b29']  / BIB Auth. Tag /
     ],
     [
        [1, h'0e365c700e4bb19c0d991faff5345aff'] h'd2c51cb2481792dae8b21d848cede99b'] / Payload Auth. Tag /
     ]
   ]

          Figure 28: Example 4: 4 - BCB Abstract Security Block (CBOR
                            Diagnostic Notation)

   The CBOR encoding of the BCB block-type-specific-data block-type-specific data field (the
   abstract security block) is 0x820301020182028202018382014c5477656c766
   531323132313282020382040782820150c95ed4534769b046d716e1cdfd00830e8201
   500e365c700e4bb19c0d991faff5345aff. is:

   0x820301020182028202018382014c5477656c766531323132313282020382040782
   81820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792dae8b2
   1d848cede99b

A.4.4.3.  Representations

   The complete BCB wrapping this abstract security block is as follows.

   [
     12, / type code                                          /
     2,  / block number                                       /
     1,  / flags - block must be replicated in every fragment /
     0,  / CRC type                                           /
     h'820301020182028202018382014c5477656c7665313231323132820203820407
       82820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d
       991faff5345aff',
       8281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792
       dae8b21d848cede99b'
   ]

           Figure 29: Example 4: 4 - BCB (CBOR Diagnostic Notation)

   The CBOR encoding of the BCB block is 0x850c0201005847820301020182028
   202018382014c5477656c766531323132313282020382040782820150c95ed4534769
   b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff. is:

   0x850c0201005849820301020182028202018382014c5477656c7665313231323132
   8202038204078281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51c
   b2481792dae8b21d848cede99b

A.4.5.  Final Bundle

   The CBOR encoding of the full output bundle, with the security blocks
   added and payload block and BIB encrypted is: 0x9f8807000082028201028
   2028202018202820201820018281a000f4240850b0300005845438ed6208eb1c1ffb9
   4d952175167df0902a815f221ebc837a134efc13bfa82a2d5d317747da3eb54acef4c
   a839bd961487284404259b60be12b8aed2f3e8a362836529f66 850c0201005847820
   301020182028202018382014c5477656c766531323132313282020382040782820150
   c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345af
   f8501010000582090eab64575930498d6aa654107f15e96319bb227706000abc8fcac
   3b9bb9c87eff.

   0x9f88070000820282010282028202018202820201820018281a000f4240850b0300
   005846438ed6208eb1c1ffb94d952175167df0902902064a2983910c4fb2340790bf
   420a7d1921d5bf7c4721e02ab87a93ab1e0b75cf62e4948727c8b5dae46ed2af0543
   9b88029191850c0201005849820301020182028202018382014c5477656c76653132
   313231328202038204078281820150220ffc45c8a901999ecc60991dd78b29818201
   50d2c51cb2481792dae8b21d848cede99b8501010000582390eab6457593379298a8
   724e16e61f837488e127212b59ac91f8a86287b7d07630a122ff

Appendix B.  CDDL Expression

   For informational purposes, Brian Sipos has kindly provided this section contains an expression of
   the IPPT and AAD structures using the Concise Data Definition
   Language (CDDL).  That CDDL expression is presented below.

   Note that wherever

   NOTES:

   *  Wherever the CDDL expression is in disagreement with the textual
      representation of the security block specification presented in
      earlier sections of this document, the textual representation
      rules.

   Note that the

   *  The structure of BP bundles and BPSec security blocks are provided
      by other specifications and specifications; this section appendix only provides the CDDL
      expression for structures uniquely defined in this specification.
      Items related to elements of a bundle, such as "primary-block",
      are defined in Appendix B of the Bundle Protocol
   Version version 7 [I-D.ietf-dtn-bpbis].

   Note that the
      [RFC9171].

   *  The CDDL itself does not have the concept of unadorned CBOR
      sequences as a top-level subject of a specification.  The current
      best practice, as documented in Section 4.1 of [RFC8742], requires
      representing the sequence as an array with a comment in the CDDL
      noting that the array represents a CBOR sequence.

   start = scope / AAD-list / IPPT-list ; satisfy CDDL decoders

   scope = uint .bits scope-flags
   scope-flags = &(
       has-primary-ctx: 0,
       has-target-ctx: 1,
       has-security-ctx: 2,
   )

   ; Encoded as a CBOR sequence
   AAD-list = [
       AAD-structure
   ]

   ; Encoded as a CBOR sequence
   IPPT-list = [
       AAD-structure,
       target-btsd: bstr ; block-type-specific-data block-type-specific data of the target block.
   ]

   AAD-structure = (
       scope,
       ? primary-block,  ; present if has-primary-ctx flag set
       ? block-metadata, ; present if has-target-ctx flag set
       ? block-metadata, ; present if has-security-ctx flag set
   )

   ; Selected fields of a canonical block
   block-metadata = (
       block-type-code: uint,
       block-number: uint,
       block-control-flags,
   )

                    Figure 30: IPPT and AAD Expressions

Appendix C.  Acknowledgements

Acknowledgments

   Amy Alford of the Johns Hopkins University Applied Physics Laboratory
   contributed useful review and analysis of these security contexts.

   Brian Sipos kindly provided the CDDL expression in Appendix B.

Authors' Addresses

   Edward J. Birrane, III
   The Johns Hopkins University Applied Physics Laboratory
   11100 Johns Hopkins Rd.
   Laurel, MD 20723
   United States of America

   Phone: +1 443 778 7423
   Email: Edward.Birrane@jhuapl.edu

   Alex White
   The Johns Hopkins University Applied Physics Laboratory
   11100 Johns Hopkins Rd.
   Laurel, MD 20723
   United States of America

   Phone: +1 443 778 0845
   Email: Alex.White@jhuapl.edu

   Sarah Heiner
   The Johns Hopkins University Applied Physics Laboratory
   11100 Johns Hopkins Rd.
   Laurel, MD 20723
   United States of America

   Phone: +1 240 592 3704
   Email: Sarah.Heiner@jhuapl.edu