Default Security Contexts for Bundle Protocol Security (BPSec)
Extracted elements (30)
AES-GCM was chosen for BCB-AES-GCM for four reasons: symmetric keys allow smaller key sizes and work without PKI; GCM produces ciphertext equal in size to plaintext (no padding), simplifying target block replacement; and AES-GCM provides authenticated encryption as required by BPSec.
HMAC-SHA2 was chosen for BIB-HMAC-SHA2 because symmetric keys allow it to be used where public-key infrastructure is impractical (as in DTN environments) and because HMAC-SHA2 is a well-supported, well-understood mechanism with multiple available implementations.
The security context identifier and security context parameters of the security block are deliberately excluded from both the IPPT (BIB-HMAC-SHA2) and AAD (BCB-AES-GCM) because these values are required to perform verification or decryption — successful processing implicitly verifies they are unchanged. Keys cannot be reused across contexts and scope flags are included in the protected data.
These security contexts are intended both for testing interoperability of BPSec implementations and for providing basic security operations when no other security contexts are defined. All context-generated information MUST be CBOR-encoded per RFC 8949.
A constant-time comparison function SHOULD be used for comparing authentication tags during BIB-HMAC-SHA2 keyed hash verification to prevent timing side-channel attacks where an attacker could guess HMAC tags by observing verifier behavior.
HMAC keys used with BIB-HMAC-SHA2 MUST be symmetric and MUST have a key length equal to the HMAC output size (i.e., multiples of 8 bytes). This ensures that special padding-aware AES key wrap algorithms are not needed.
Prior to generating the IPPT, if a CRC value is present for the target block of the BIB, that CRC MUST be removed from the target block and the CRC type field set to 'no CRC is present.' If the security acceptor is not the bundle destination and no other integrity service applies, a CRC MUST be included for the target block upon completion.
The integrity scope flags MUST always be included in the IPPT value itself, even when they are not included in the BIB as a security context parameter. Reserved and unassigned bits MUST be set to 0 at the security source and the value MUST NOT be altered until the security service is completed.
The output of the HMAC in BIB-HMAC-SHA2 MUST be equal to the size of the SHA-2 hashing function used: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits for SHA-512.
The pairing of a per-invocation IV and a security key in BCB-AES-GCM MUST be unique; a per-invocation IV MUST NOT be used with a security key more than once. Reuse makes the GCM implementation vulnerable to forgery attacks with catastrophic security consequences.
The plaintext for BCB-AES-GCM encryption MUST be the value of the block-type-specific data field of the security target excluding the BP CBOR byte string encoding wrapper. Similarly the ciphertext for decryption excludes the CBOR byte string identifying byte and optional length field.
The same key (whether a KEK or wrapped key) MUST NOT be used for different algorithms, as doing so might leak key material. A KEK MUST NOT be used to wrap keys for different security contexts; a KEK for BIB-HMAC-SHA2 must not be used to wrap keys for BCB-AES-GCM.
The total number of invocations of the AES-GCM authenticated encryption function with a single key is required not to exceed 2^32, and the total number of AES blocks processed with a single key is recommended to be less than 2^64, as per NIST SP 800-38D.
BCB-AES-GCM is a confidentiality security context that replaces the block-type-specific data field of its security target with AES-GCM ciphertext. It also generates an authentication tag over the plaintext and optional additional authenticated data (AAD). The security context identifier is assigned value 2.
BIB-HMAC-SHA2 is an integrity security context providing a keyed-hash MAC over plaintext (the IPPT) using HMAC combined with SHA-2. It supports three variants: HMAC 256/256, HMAC 384/384, and HMAC 512/512, selected via a security context parameter. The security context identifier is assigned value 1 in the BPSec Security Context Identifiers registry.
The Integrity-Protected Plaintext (IPPT) for BIB-HMAC-SHA2 is constructed by concatenating: (1) CBOR encoding of the integrity scope flags, (2) optionally the canonical primary block, (3) optionally the canonical target block header fields, (4) optionally the canonical BIB header fields, and (5) the canonical block-type-specific data of the security target.
IANA created the 'BPSec BCB-AES-GCM AAD Scope Flags' registry (16-bit unsigned integer range, Specification Required policy) with initial entries: bit 0 = include primary block flag, bit 1 = include target header flag, bit 2 = include security header flag, bits 3-7 reserved, bits 8-15 unassigned.
IANA created the 'BPSec BIB-HMAC-SHA2 Integrity Scope Flags' registry (16-bit unsigned integer range, Specification Required policy) with initial entries: bit 0 = include primary block flag, bit 1 = include target header flag, bit 2 = include security header flag, bits 3-7 reserved, bits 8-15 unassigned.
This document allocates two entries in the IANA 'BPSec Security Context Identifiers' registry: value 1 for BIB-HMAC-SHA2 and value 2 for BCB-AES-GCM, both referencing RFC 9173.
Bundle fragmentation can prevent BPSec security services from being processed: a security block and its target may end up in different fragments; security blocks cryptographically bound to the primary block cannot be processed in fragments (fragments have different primary blocks); and the same operation may verify in one fragment but fail in another.
DTN key management is fundamentally challenged because round-trip key exchange protocols may not converge in delay-tolerant networks with substantial propagation delay, highly challenged communications, or unidirectional nodes. Certificate-authority-based revocation similarly fails; therefore both security contexts rely on symmetric-key mechanisms.
GCM has no inherent replay attack protection; because delay-tolerant networks have a higher occurrence of replay attacks due to store-and-forward behavior, implementors SHOULD detect replay attacks using mechanisms such as those in Appendix D of NIST SP 800-38D.
Implementations SHOULD limit the number of unsuccessful AES-GCM verification attempts per key to reduce the likelihood of tag guessing. When AES-KW is used, an attacker could cause a large number of keys to be used at least once, creating state-keeping challenges for this check.
The BCB-AES-GCM AAD Scope Flags parameter (Parm Id 4) is a CBOR unsigned integer processed as a 16-bit field. Bit 0 = include primary block, Bit 1 = include target header, Bit 2 = include security header. Default value is 7. These flags MUST be included in the AAD value itself even if omitted from the BCB.
The BCB-AES-GCM AES Variant parameter (Parm Id 2) is a CBOR unsigned integer. Value 1 = A128GCM, value 3 = A256GCM (default). Regardless of variant, the generated authentication tag MUST always be 128 bits.
The BCB-AES-GCM Authentication Tag result (Result Id 1) is a CBOR byte string and MUST be 128 bits prior to CBOR encoding. It MAY be stored as a BCB security result or included with the ciphertext in the security target block-type-specific data field.
The BCB-AES-GCM Initialization Vector parameter (Parm Id 1) is a CBOR byte string. Its length prior to CBOR encoding MUST be between 8 and 16 bytes; 12 bytes SHOULD be used unless policy requires otherwise. The IV MUST NOT be reused with the same encryption key.
The BIB-HMAC-SHA2 Integrity Scope Flags parameter (Parm Id 3) is a CBOR unsigned integer processed as a 16-bit field (max 65535). Bit 0 = include primary block, Bit 1 = include target header, Bit 2 = include security header. Default value is 7 (all assigned bits set).
The BIB-HMAC-SHA2 SHA Variant parameter (Parm Id 1) is a CBOR unsigned integer. Valid values are 5 (HMAC 256/256), 6 (HMAC 384/384), and 7 (HMAC 512/512), matching RFC 8152 Table 7. Default is 6 when not provided.
The Wrapped Key parameter (Parm Id 2 in both BIB-HMAC-SHA2 and BCB-AES-GCM) is a CBOR byte string carrying the output of the AES key wrap function (RFC 3394) applied to the symmetric content key. If absent, security verifiers and acceptors MUST determine the key via local BPSec policy.