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.

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

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

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.

Bit 0 (the low-order bit, 0x0001):

Include primary block flag

Bit 1 (0x0002):

Include target header flag

Bit 2 (0x0004):

Include security header flag

Bits 3-7:

Reserved

Bits 8-15:

Unassigned

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

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 and thesecurity target is not the bundle's primary block, then a canonical form ofthe bundle's primary block MUST be calculated and the resultappended to the IPPT.
3. If the target header flag of the integrity scope flags is set to 1 and thesecurity target is not the bundle's primary block, then the canonical form ofthe block type code, block number, and block processing control flagsassociated with the security target MUST be calculated and, inthat 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 MUST be calculatedand appended to the IPPT. If the security target is the primary block, this isthe canonical form of the primary block. Otherwise, this is the canonical formof the block-type-specific data of the security target.

• 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 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 Section 3.7.

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

• 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 context parameter, in which case it MUST be wrapped using the AES key wrap function as defined in [RFC 3394] 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.

• 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, then these flags MAY be derived from local security policy.

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 ciphertext with the same size as the 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.

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.

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, then the policy for handling the security target has been modified.

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

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

Bit 0 (the low-order bit, 0x0001):

Include primary block flag

Bit 1 (0x0002):

Include target header flag

Bit 2 (0x0004):

Include security header flag

Bits 3-7:

Reserved

Bits 8-15:

Unassigned

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

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

• 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 [AES-GCM]. Methods of generating unique IV values are provided in Section 8 of [AES-GCM]. 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 [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 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 be used at least once.
• As discussed in Section 8 of [RFC 9172], 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].

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.

• 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 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, with the value of AAD scope flags being taken from local security policy.

• The ciphertext produced by AES-GCM MUST replace the bytes used to define the 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 ciphertext is larger than the plaintext (which can occur when the authentication tag is included in the ciphertext calculation, as discussed in Section 4.4).
• 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 Section 4.4.
• The authentication tag MUST be included either as a security result in the BCB representing the security operation or (with the ciphertext) in the security target block-type-specific data field.

• 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 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 context parameter, in which case it MUST be wrapped using the AES key wrap function as defined in [RFC 3394] 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.

• 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, 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, 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 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, 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 ciphertext) in the security target block-type-specific data field.

• The plaintext produced by AES-GCM MUST replace the bytes used to define the 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 plaintext has a different length than the replaced ciphertext.

• Ascertain the existence of suitable documentation (a specification) as described in [RFC 8126] and verify that the document is permanently and publicly available.
• Ensure that any changes to the "BPSec BIB-HMAC-SHA2 Integrity Scope 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" 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.

• Establish shared KEKs with other nodes in the network using an out-of-band mechanism. This might include pre-sharing of KEKs or the use of older 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.

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

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

[AES-GCM]

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

[RFC2104]

H. Krawczyk, M. Bellare, 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]

S. Bradner, "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>.

[RFC3394]

J. Schaad, and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002,
<https://www.rfc-editor.org/info/rfc3394>.

[RFC8126]

M. Cotton, B. Leiba, 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]

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

[RFC8174]

B. Leiba, "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]

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

[RFC8949]

C. Bormann, 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]

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

[RFC9172]

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

[SHS]

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

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

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

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

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

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

• 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 Appendix B of RFC 9171.
• 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 RFC 8742, 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 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,
)

Edward J. Birrane, III

Alex White

Sarah Heiner