Bundle Protocol Security Protocol (BPSec) Default Security Contexts

Bundle Protocol Security Protocol (BPSec) Default Security Contexts The Johns Hopkins University Applied Physics Laboratory

11100 Johns Hopkins Rd. Laurel MD 20723 US +1 443 778 7423 Edward.Birrane@jhuapl.edu

The Johns Hopkins University Applied Physics Laboratory

11100 Johns Hopkins Rd. Laurel MD 20723 US +1 443 778 0845 Alex.White@jhuapl.edu

The Johns Hopkins University Applied Physics Laboratory

11100 Johns Hopkins Rd. Laurel MD 20723 US +1 240 592 3704 Sarah.Heiner@jhuapl.edu

General Delay-Tolerant Networking security bundle integrity confidentiality This document defines default integrity and confidentiality security contexts that can be used with Bundle Protocol Security Protocol (BPSec) implementations. These security contexts are intended to be used 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.

Introduction The Bundle Protocol Security Protocol (BPSec) specification provides inter-bundle integrity and confidentiality operations for networks deploying the Bundle Protocol (BP) . 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 Concise Binary Object Representation (CBOR) specification documented in .

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 when, and only when, they appear in all capitals, as shown here.

Integrity Security Context BIB-HMAC-SHA2

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

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.
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, and HMAC 512/512 as defined in Table 7 ("HMAC Algorithm Values") of . 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 .

Scope The scope of BIB-HMAC-SHA2 is the set of information used to produce the plain text over which a keyed hash is calculated. This plain text is termed the "Integrity-Protected Plain Text (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 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: The determination of which optional types of information were used when constructing the IPPT MUST, itself, 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 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 fields: 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, 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 fields: 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 reused across security 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.

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

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 Table 7 ("HMAC Algorithm Values") of
6	HMAC 384/384 as defined in Table 7 ("HMAC Algorithm Values") of
7	HMAC 512/512 as defined in Table 7 ("HMAC Algorithm Values") of

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.

Wrapped Key This optional parameter contains the output of the AES key wrap authenticated encryption function (KW-AE) as defined in . Specifically, this parameter holds the cipher text produced when running the KW-AE 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, then security verifiers and acceptors MUST determine the proper key as a function of their local BPSec policy and configuration.

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. 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
Bit 1 (0x0002):: Target Header Flag
Bit 2 (0x0004):: Security Header Flag
Bits 3-7:: Reserved
Bits 8-15:: Unassigned

Enumerations The BIB-HMAC-SHA2 security context parameters are listed in . In this table, the "Parm Id" column refers to the expected parameter identifier described in Section "Parameter and Result Identification" of . An empty "Default Value" column indicates that the security 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
3	Integrity Scope Flags	unsigned integer	7

Results The BIB-HMAC-SHA2 security context results are listed in . In this table, the "Result Id" column refers to the expected result identifier described in Section "Parameter and Result Identification" of . BIB-HMAC-SHA2 Security Results

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

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 integers divisible by 8 bytes, and special 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 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 and emphasized here, it is strongly recommended that keys be protected once generated, both when they are stored and when they are transmitted.

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 guess at an HMAC tag and observe the behavior of a verifier. With a modest number of trials, a side-channel attack could produce an HMAC tag for attacker-provided plain text 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.

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 as described in . The canonicalization algorithms defined in adhere to the canonical forms for extension blocks defined in 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.

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.
If the primary block flag of the integrity 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 IPPT.
If the target 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 security target MUST be calculated and, in that order, appended to the IPPT.
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.
The canonical form of the security target block-type-specific data MUST be calculated and appended to the IPPT.

Processing

Keyed Hash Generation During keyed hash generation, 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 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 through some other key management mechanism as discussed in .
Prior to the generation of the IPPT, if a 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 field of the target block to "no CRC is present."
Once CRC information is removed, the IPPT MUST be generated as discussed in .

Upon successful hash generation, the following actions 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 .

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 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, in which case it MUST be wrapped using the NIST AES-KW algorithm and the results of the wrapping added as the wrapped key security parameter for the BIB.
The SHA variant used by this security context SHOULD be added as the SHA variant security 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.

Keyed Hash Verification During keyed hash verification, the input of the security target and 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 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 .
The IPPT MUST be generated as discussed in 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, 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 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 . 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, and the corresponding CRC value is added as the CRC field for that block.

Security Context BCB-AES-GCM

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

The selection of a symmetric-key cipher suite allows for relatively smaller keys than asymmetric-key cipher suites.
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.
The use of the Galois/Counter Mode produces cipher text with the same size as the plain text making the replacement of target block information easier as length fields do not need to be changed.
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 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 Table 9 ("Algorithm Value for AES-GCM") of . The BCB-AES-GCM security context MUST have the security context identifier specified in .

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. 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. This MUST be the full set of plain text 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 and the scope flags used to identify other optional information; it MAY include other information (additional authenticated data), as follows.

Primary block: The primary block identifies a 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 fields: 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, 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 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 fields: 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, 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 reused across security 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.

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

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, with the caveat that a value MUST NOT be reused for multiple encryptions using the same encryption key. This value MAY be 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.

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 Table 9 ("Algorithm Value for AES-GCM") of
3	A256GCM as defined in Table 9 ("Algorithm Value for AES-GCM") of

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.

Wrapped Key This optional parameter contains the output of the AES key wrap authenticated encryption function (KW-AE) as defined in . Specifically, this parameter holds the cipher text produced when running the KW-AE 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, then security verifiers and acceptors MUST determine the proper key as a function of their local BPSec policy and configuration.

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. 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
Bit 1 (0x0002):: Target Header Flag
Bit 2 (0x0004):: Security Header Flag
Bits 3-7:: Reserved
Bits 8-15:: Unassigned

Enumerations The BCB-AES-GCM security context parameters are listed in . In this table, the "Parm Id" column refers to the expected parameter identifier described in Section "Parameter and Result Identification" of . An empty "Default Value" column indicates that the security parameter does not have a default value. BCB-AES-GCM Security Parameters

Parm Id	Parm Name	CBOR Encoding Type	Default Value
1	Initialization Vector	Byte String
2	AES Variant	Unsigned Integer	3
3	Wrapped Key	Byte String
4	AAD Scope Flags	Unsigned Integer	7

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

The cipher text 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 of the same size as its plain text; therefore, no additional logic is required to handle padding or overflow caused by the encryption in most cases (see below).
If the authentication tag can be separated from the cipher text, 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 replacing the block-type-specific-data field of the security target block.

Authentication Tag The authentication tag is generated by the cipher suite over the security target plain text input to the cipher suite as combined with any optional additional authenticated data. This tag is used to ensure that the plain text (and important information associated with the plain text) is authenticated prior to decryption. If the authentication tag is included in the cipher text 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.

Enumerations The BCB-AES-GCM security context results are listed in . In this table, the "Result Id" column refers to the expected result identifier described in Section "Parameter and Result Identification" of . BCB-AES-GCM Security Results

Result Id	Result Name	CBOR Encoding Type
1	Authentication Tag	Byte String

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 integers divisible by 8 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) 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⁶⁴, as described in Appendix B of . 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³², as described in Section 8.3 of . As discussed in and emphasized here, it is strongly recommended that keys be protected once generated, both when they are stored and when they are transmitted.

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 , 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, 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 . Methods of generating unique IV values are provided in Section 8 of . For example, one method decomposes the IV value into a fixed field and an invocation field. The fixed field is a constant value associated with a device, and the invocation field changes on each invocation (such as by incrementing an integer counter). Implementers SHOULD carefully read all relevant sections of 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 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 .
As discussed in Appendix B of , 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 be used at least once.
As discussed in Section "Security Considerations" of , 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 .

Canonicalization Algorithms This section defines the canonicalization algorithms used to prepare the inputs used to generate both the cipher text and the authentication tag. In all cases, the canonical form of any portion of an extension block MUST be performed as described in . The canonicalization algorithms defined in adhere to the canonical forms for extension blocks defined in but resolve ambiguities related to how values are represented in CBOR.

Calculations Related to Cipher Text 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 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. shows two CBOR-encoded examples and the plain text 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 Part (Hex)	Plain Text Part (Hex)
18ED	18	ED
C24CDEADBEEFDEADBEEFDEADBEEF	C24C	DEADBEEFDEADBEEFDEADBEEF

Similarly, the cipher text used during decryption MUST be calculated as the single, definite-length CBOR byte string representing the 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.

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.

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

Processing

Encryption During encryption, four inputs are prepared for input to the AES/GCM cipher: the encryption key, the IV, the security target plain text 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 through some other key management mechanism as discussed in .
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 for encryption MUST be generated as discussed in .
Additional authenticated data MUST be generated as discussed in , with the value of AAD scope flags being taken from local security policy.

Upon successful encryption, the following actions MUST occur.

The cipher text produced by AES/GCM MUST replace the bytes used to define the plain text 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 is larger than the plain text (which can occur when the authentication tag is included in the cipher text calculation, as discussed in ).
The authentication tag calculated by the 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 .
The authentication tag MUST be included either as a security result in the BCB representing the security operation or (with the cipher text) 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 parameter for the BCB.
Any local flags used to generate AAD for this cipher MUST be placed in the AAD scope flags security 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, in which case it MUST be wrapped using the NIST AES-KW algorithm and the results of the wrapping added as the wrapped key security parameter for the BCB.
The AES variant used by this security context SHOULD be added as the AES variant security 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.

Decryption During decryption, five inputs are prepared for input to the AES/GCM cipher: the decryption key, the IV, the security target cipher text 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 parameter if such a parameter is included in the security context parameters of the BCB. Otherwise, this key MUST be derived in accordance with local security policy at the decrypting node as discussed in .
The IV MUST be set to the value of the IV security parameter included in the BCB. If the IV parameter is not included as a security parameter, an IV MAY be derived as a function of local security policy and other BCB contents, or a lack of an IV security parameter in the BCB MAY be treated as an error by the decrypting node.
The security target cipher text for decryption MUST be generated as discussed in .
Additional authenticated data MUST be generated as discussed in 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, 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) in the security target block-type-specific data field.

Upon successful decryption the following actions MUST occur.

The plain text produced by AES/GCM MUST replace the bytes used to define the cipher text 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 has a different length than the replaced cipher text.

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 fails to authenticate, if any needed parameters are missing, or if there are other problems in the decryption, then the decryption MUST be treated as failed and processed in accordance with local security policy.

IANA Considerations

Security Context Identifiers This specification allocates two security context identifiers from the "BPSec Security Context Identifiers" registry defined in . Additional Entries for the BPSec Security Context Identifiers Registry

Value	Description	Reference
1	BIB-HMAC-SHA2	RFC 9173
2	BCB-AES-GCM	RFC 9173

Integrity Scope Flags The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field for which IANA has created and now maintains a new registry named "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the "Bundle Protocol" registry page. shows the initial values for this registry. The registration policy for this registry is Specification Required . 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	RFC 9173
1	Include target header flag	RFC 9173
2	Include security header flag	RFC 9173
3-7	Reserved	RFC 9173
8-15	Unassigned

AAD Scope Flags The BCB-AES-GCM security context has an AAD Scope Flags field for which IANA has created and now maintains a new registry named "BPSec BCB-AES-GCM AAD Scope Flags" on the "Bundle Protocol" registry page. shows the initial values for this registry. The registration policy for this registry 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	RFC 9173
1	Include target header flag	RFC 9173
2	Include security header flag	RFC 9173
3-7	Reserved	RFC 9173
8-15	Unassigned

Guidance for Designated Experts New assignments within the "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" and "BPSec BCB-AES-GCM AAD Scope 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 and verify that the document is permanently and publicly available.
Ensure that any changes to the Integrity Scope Flags 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 AAD Scope Flags 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.

Security Considerations Security considerations specific to a single security context are provided in the description of that context (see Sections and ). 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 should also be reviewed by security context implementors.

Key Management The delayed and disrupted nature of Delay-Tolerant Networks (DTNs) complicates the process of key management because there might not be reliable, 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 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 cryptographic mechanisms because 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" . This assumption is also made by the security contexts defined in this document, which do not define new protocols for key derivation, exchange of key-encrypting keys, 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 with other nodes in the network using an out-of-band mechanism. This might include pre-sharing of key encryption keys or the use of traditional key establishment mechanisms prior to the exchange of 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, including local security policy, time relative to the generation or use of the key, or 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.

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, 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 or a wrapped key, MUST NOT be used for different algorithms as doing so might leak information about the key.
A key-encrypting-key MUST NOT be used to encrypt keys for different security contexts. Any key-encrypting-key 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 to wrap keys for both the 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 to unwrap keys for different security contexts.

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 as part of the documentation of the BCB-AES-GCM security context. The length of the cipher text produced by the GCM mode of AES will be equal to the length of the plain text input to the cipher suite. The authentication tag also produced by this cipher suite is separate from the cipher text. However, it should be noted that implementations of the AES-GCM cipher suite might not separate the concept of cipher text and authentication tag in their 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 replacing the 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 and authentication tag MUST be processed in accordance with the API of the AES-GCM cipher suites at the security source and security acceptor.

AES Key Wrap The AES key wrap (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 provided by local security policy at the security verifier or security acceptor.

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 (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 (for BIB-HMAC-SHA2) or the AAD 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.

Normative References Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC Secure Hash Standard (SHS) National Institute of Standards and Technology Bundle Protocol Version 7 Bundle Protocol Security Specification

Examples This appendix is informative. This 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 parameters, security results, or use of security blocks in a bundle. NOTES:

The bundle diagrams in this appendix are patterned after the bundle diagrams used in Section "BSP Block Examples" of .
Figures in this appendix identified as "(CBOR Diagnostic Notation)" are represented using the CBOR diagnostic notation defined in . 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 .
Examples in this appendix use the "ipn" URI scheme for Endpoint ID naming, as defined in .
The bundle source is presumed to be the security source for all security blocks in this appendix, unless otherwise noted.

Example 1: Simple Integrity This example shows the addition of a BIB to a sample bundle to provide integrity for the payload block.

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

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

Primary Block The BPv7 bundle has no special processing 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 indicating lack of an accurate clock and 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.

Primary Block (CBOR Diagnostic Notation) The CBOR encoding of the primary block is 0x88070000820282010282028202018202820201820018281a000f4240.

Payload Block Other than its use as a source of plain text 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". 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. The payload block is provided as follows.

Payload Block (CBOR Diagnostic Notation) The CBOR encoding of the payload block is 0x8501010000582052656164792047656e657261746520612033322062797465207061796c6f6164.

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

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.

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

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

Configuration, Parameters, and Results For this example, the following configuration and security 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.

Example 1: Configuration, Parameters, and Results Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' SHA Variant : HMAC 512/512 Scope Flags : 0x00 Payload Data: h'52656164792047656e65726174652061 2033322062797465207061796c6f6164' Signature : h'0654d65992803252210e377d66d0a8dc 18a1e8a392269125ae9ac198a9a598be 4b83d5daa8be2f2d16769ec1c30cfc34 8e2205fba4b3be2b219074fdd5ea8ef0'

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

Example 1: BIB Abstract Security Block (CBOR Diagnostic Notation) The CBOR encoding of the BIB block-type-specific-data field (the abstract security block) is 0x8101010182028202018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0.

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

Example 1: BIB (CBOR Diagnostic Notation) The CBOR encoding of the BIB block is 0x850b02000058558101010182028202018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0.

Final Bundle The CBOR encoding of the full output bundle, with the BIB: 0x9f88070000820282010282028202018202820201820018281a000f4240850b0200005855810101018202820201828201078203008182015840 0654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef08501010000582052656164792047656e657261746520612033322062797465207061796c6f6164ff.

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

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

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

Primary Block The primary block used in this example is identical to the primary block presented for Example 1 in . In summary, the CBOR encoding of the primary block is 0x88070000820282010282028202018202820201820018281a000f4240.

Payload Block The payload block used in this example is identical to the payload block presented for Example 1 in . In summary, the CBOR encoding of the payload block is 0x8501010000582052656164792047656e657261746520612033322062797465207061796c6f6164.

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.

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

Bundle Confidentiality Block In this example, a BCB is used to encrypt the payload block and uses AES key wrap to transmit the symmetric key.

Configuration, Parameters, and Results For this example, the following configuration and security parameters are used to generate the security results indicated. This BCB has a single target -- the payload block. Three security results are generated: cipher text that replaces the plain text block-type-specific data to encrypt the payload block, an authentication tag, and the AES wrapped key.

Example 2: Configuration, Parameters, and Results 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' Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 a563e32648b700c2784e26a990d91f9d'

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

Example 2: BCB Abstract Security Block (CBOR Diagnostic Notation) The CBOR encoding of the BCB block-type-specific-data field (the abstract security block) is 0x8101020182028202018482014c5477656c76653132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e73dd97.

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

Example 2: BCB (CBOR Diagnostic Notation) The CBOR encoding of the BCB block is 0x850c020100584f8101020182028202018482014c5477656c76653132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e73dd97.

Final Bundle The CBOR encoding of the full output bundle, with the BCB: 0x9f88070000820282010282028202018202820201820018281a000f4240850c020100584f8101020182028202018482014c5477656c76653132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e73dd97850101000058203a09c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff.

Example 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, 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 and Bundle Age Block.

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

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

Bundle Age Block A 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 extension block is provided as follows.

Bundle Age Block (CBOR Diagnostic Notation) > / type-specific-data: age / ] ]]> The CBOR encoding of the bundle age block is 0x85070200004319012c.

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

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

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

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

Configuration, Parameters, and Results For this example, the following configuration and security 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 and primary block.

Example 3: Configuration, Parameters, and Results for the BIB Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' SHA Variant: HMAC 256/256 Scope Flags: 0x00 Primary Block Data: h'88070000820282010282028202018202 820201820018281a000f4240' Bundle Age Block Data: h'85070200004319012c' Primary Block Signature: h'8e059b8e71f7218264185a666bf3e453 076f2b883f4dce9b3cdb6464ed0dcf0f' Bundle Age Block Signature: h'72dee8eba049a22978e84a95d0496466 8eb131b1ca4800c114206d70d9065c80'

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

Example 3: BIB Abstract Security Block (CBOR Diagnostic Notation) The CBOR encoding of the BIB block-type-specific-data field (the abstract security block) is 0x820002010182028203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80.

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

Example 3: BIB (CBOR Diagnostic Notation) The CBOR encoding of the BIB block is 0x850b030000585a820002010182028203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80.

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

Configuration, Parameters, and Results For this example, the following configuration and security 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 that replaces the plain text block-type-specific data to encrypt the payload block and an authentication tag.

Example 3: Configuration, Parameters, and Results for the BCB Content Encryption Key: h'71776572747975696f70617364666768' IV: h'5477656c7665313231323132' AES Variant: A128GCM Scope Flags: 0x00 Payload Data: h'52656164792047656e65726174652061 2033322062797465207061796c6f6164' Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 a563e32648b700c2784e26a990d91f9d'

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

Example 3: BCB Abstract Security Block (CBOR Diagnostic Notation) The CBOR encoding of the BCB block-type-specific-data field (the abstract security block) is 0x8101020182028202018382014c5477656c766531323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd97.

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

Example 3: BCB (CBOR Diagnostic Notation) The CBOR encoding of the BCB block is 0x850c04010058338101020182028202018382014c5477656c766531323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd97.

Final Bundle The CBOR encoding of the full output bundle, with the BIB and BCB added is: 0x9f88070000820282010282028202018202820201820018281a000f4240850b030000585a820002010182028203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80850c04010058338101020182028202018382014c5477656c766531323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd9785070200004319012c850101000058203a09c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff.

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

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

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

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.

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

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

Example 4: Configuration, Parameters, and Results for the BIB Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' SHA Variant: HMAC 384/384 Scope Flags: 0x07 (all additional headers) Primary Block Data: h'88070000820282010282028202018202 820201820018281a000f4240 Payload Data: h'52656164792047656e65726174652061 2033322062797465207061796c6f6164' Payload Header: h'85010100005820' BIB Header: h'850b0300005845' Payload Signature: h'07c84d929f83bee4690130729d77a1bd da9611cd6598e73d0659073ea74e8c27 523b02193cb8ba64be58dbc556887aca

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

Example 4: BIB Abstract Security Block (CBOR Diagnostic Notation) The CBOR encoding of the BIB block-type-specific-data field (the abstract security block) is 0x81010101820282020182820106820307818201583007c84d929f83bee4690130729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58dbc556887aca.

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

Example 4: BIB (CBOR Diagnostic Notation) The CBOR encoding of the BIB block is 0x850b030000584581010101820282020182820106820307818201583007c84d929f83bee4690130729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58dbc556887aca.

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

Configuration, Parameters, and Results For this example, the following configuration and security 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 that replaces the plain text block-type-specific data of the payload block, cipher text to encrypt the BIB, and authentication tags for both the payload block and BIB.

Example 4: Configuration, Parameters, and Results for the BCB Key: h'71776572747975696f70617364666768 71776572747975696f70617364666768' IV: h'5477656c7665313231323132' AES Variant: A256GCM Scope Flags: 0x07 (All additional headers) Payload Data: h'52656164792047656e65726174652061 2033322062797465207061796c6f6164' BIB Data: h'81010101820282020182820106820307 818201583007c84d929f83bee4690130 729d77a1bdda9611cd6598e73d065907 3ea74e8c27523b02193cb8ba64be58db c556887aca BIB Authentication Tag: h'c95ed4534769b046d716e1cdfd00830e' Payload Block Authentication Tag: h'0e365c700e4bb19c0d991faff5345aff' Payload Ciphertext: h'90eab64575930498d6aa654107f15e96 319bb227706000abc8fcac3b9bb9c87e' BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0 902a815f221ebc837a134efc13bfa82a 2d5d317747da3eb54acef4ca839bd961 487284404259b60be12b8aed2f3e8a36 2836529f66'

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

Example 4: BCB Abstract Security Block (CBOR Diagnostic Notation) The CBOR encoding of the BCB block-type-specific-data field (the abstract security block) is 0x820301020182028202018382014c5477656c766531323132313282020382040782820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff.

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

Example 4: BCB (CBOR Diagnostic Notation) The CBOR encoding of the BCB block is 0x850c0201005847820301020182028202018382014c5477656c766531323132313282020382040782820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff.

Final Bundle The CBOR encoding of the full output bundle, with the security blocks added and payload block and BIB encrypted is: 0x9f88070000820282010282028202018202820201820018281a000f4240850b03000 05845438ed6208eb1c1ffb94d952175167df0902a815f221ebc837a134efc13bfa82a 2d5d317747da3eb54acef4ca839bd961487284404259b60be12b8aed2f3e8a3628365 29f66850c0201005847820301020182028202018382014c5477656c76653132313231 3282020382040782820150c95ed4534769b046d716e1cdfd00830e8201500e365c700 e4bb19c0d991faff5345aff8501010000582090eab64575930498d6aa654107f15e96 319bb227706000abc8fcac3b9bb9c87eff.

CDDL Expression For informational purposes, has kindly provided an expression of the IPPT and AAD structures using the Concise Data Definition Language (CDDL). That CDDL expression is presented below. 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.
The structure of BP bundles and BPSec security blocks are provided by other specifications; this 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 the Bundle Protocol version 7.
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 , requires representing the sequence as an array with a comment in the CDDL noting that the array represents a CBOR sequence.

IPPT and AAD Expressions

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