| RFC 9173 | BPSec Default Security Contexts | January 2022 |
| Birrane, III, et al. | Standards Track | [Page] |
This document defines default integrity and confidentiality security contexts that can be used with Bundle Protocol Security (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.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9173.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Bundle Protocol Security (BPSec) specification[RFC9172] provides inter-bundle integrity and confidentiality operations for networks deploying the Bundle Protocol (BP)[RFC9171]. BPSec defines BP extension blocks to carry security information produced under the auspices of some security context.¶
This document defines two security contexts (one for an integrity service and one for a confidentiality service) for populating BPSec Block Integrity Blocks (BIBs) and Block Confidentiality Blocks (BCBs). This document assumes familiarity with the concepts and terminology associated with BP and BPSec, as these security contexts are used with BPSec security blocks and other BP blocks carried within BP bundles.¶
These contexts generate information thatMUST be encoded using the Concise Binary Object Representation (CBOR) specification documented in[RFC8949].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The BIB-HMAC-SHA2 security context provides a keyed-hash Message Authentication Code (MAC) over a set of plaintext information. This context uses the Secure Hash Algorithm 2 (SHA-2) discussed in[SHS] combined with the Hashed Message Authentication Code (HMAC) keyed hash discussed in[RFC2104]. The combination of HMAC and SHA-2 as the integrity mechanism for this security context was selected for two reasons:¶
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[RFC8152]. The selection of which variant is used by this context is provided as a security context parameter.¶
The output of the HMACMUST 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 contextMUST have the security context identifier specified inSection 5.1.¶
The scope of BIB-HMAC-SHA2 is the set of information used to produce the plaintext over which a keyed hash is calculated. This plaintext is termed the "Integrity-Protected Plaintext (IPPT)". The content of the IPPT is constructed as the concatenation of information whose integrity is being preserved from the BIB-HMAC-SHA2 security source to its security acceptor. There are five types of information that can be used in the generation of the IPPT, based on how broadly the concept of integrity is being applied. These five types of information, whether they are required, and why they are important for integrity are discussed as follows.¶
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.¶
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.¶
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.¶
BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, communicate key information, and define the scope of the IPPT.¶
This optional parameter identifies which variant of the SHA-2 algorithm is to be used in the generation of the authentication code.¶
This valueMUST be encoded as a CBOR unsigned integer.¶
Valid values for this parameter are as follows.¶
| Value | Description |
|---|---|
| 5 | HMAC 256/256 as defined in Table 7 ("HMAC Algorithm Values") of[RFC8152] |
| 6 | HMAC 384/384 as defined in Table 7 ("HMAC Algorithm Values") of[RFC8152] |
| 7 | HMAC 512/512 as defined in Table 7 ("HMAC Algorithm Values") of[RFC8152] |
When not provided, implementationsSHOULD 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.¶
This optional parameter contains the output of the AES key wrap function as defined in[RFC3394]. Specifically, this parameter holds the ciphertext produced when running this key wrap algorithm with the input string being the symmetric HMAC key used to generate the security results present in the security block. The value of this parameter is used as input to the AES key wrap authenticated decryption function 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 valueMUST be encoded as a CBOR byte string.¶
If this parameter is not present, then security verifiers and acceptorsMUST determine the proper key as a function of their local BPSec policy and configuration.¶
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 valueMUST be represented as a CBOR unsigned integer, the value of whichMUST be processed as a 16-bit field. The maximum value of this field, as a CBOR unsigned integer,MUST be 65535.¶
When not provided, implementationsSHOULD assume a value of 7 (indicating all assigned fields), unless an alternate default is established by local security policy at the security source, verifier, or acceptor of this integrity service.¶
ImplementationsMUST set reserved and unassigned bits in this field to 0 when constructing these flags at a security source. Once set, the value of this fieldMUST 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.¶
The BIB-HMAC-SHA2 security context parameters are listed inTable 2. In this table, the "Parm Id" column refers to the expected parameter identifier described in Section3.10 ("Parameter and Result Identification") of[RFC9172].¶
An empty "Default Value" column indicates that the security context parameter does not have a default value.¶
| 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 |
The BIB-HMAC-SHA2 security context results are listed inTable 3. In this table, the "Result Id" column refers to the expected result identifier described in Section3.10 ("Parameter and Result Identification") of[RFC9172].¶
| Result Id | Result Name | CBOR Encoding Type | Description |
|---|---|---|---|
| 1 | Expected HMAC | byte string | The output of the HMAC calculation at the security source. |
HMAC keys used with this contextMUST be symmetric andMUST 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:¶
When an AES Key Wrap (AES-KW)[RFC3394] wrapped key is present in a security block, it is assumed that security verifiers and security acceptors can independently determine the key encryption key (KEK) used in the wrapping of the symmetric HMAC key.¶
As discussed inSection 6 and emphasized here, it is strongly recommended that keys be protected once generated, both when they are stored and when they are transmitted.¶
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 plaintext, 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 plaintext without the attacker ever knowing the HMAC key.¶
A common method of observing the behavior of a verifier is precise analysis of the timing associated with comparisons. Therefore, one way to prevent behavior analysis of this type is to ensure that any comparisons of the supplied and expected authentication tag occur in constant time.¶
A constant-time comparison functionSHOULD 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.¶
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 blockMUST be created as described in[RFC9172]. The canonicalization algorithms defined in[RFC9172] adhere to the canonical forms for extension blocks defined in[RFC9171] but resolve ambiguities related to how values are represented in CBOR.¶
The IPPT is constructed using the following process. While integrity scope flags might not be included in the BIB representing the security operation, theyMUST be included in the IPPT value itself.¶
NOTE: When the security target is the bundle's primary block, the canonicalization steps associated with the primary block flag and the target header flag are skipped. Skipping primary block flag processing, in this case, avoids adding the bundle's primary block twice in the IPPT calculation. Skipping target header flag processing, in this case, is necessary because the primary block of a bundle does not have the expected elements of a block header such as block number and block processing control flags.¶
During keyed hash generation, two inputs are prepared for the appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These data itemsMUST be generated as follows.¶
Upon successful hash generation, the following actionMUST occur.¶
Finally, the BIB containing information about this security operationMUST be updated as follows. These operations can occur in any order.¶
Problems encountered in the keyed hash generationMUST be processed in accordance with local BPSec security policy.¶
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 itemsMUST be generated as follows.¶
The calculated HMAC outputMUST 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 verificationMUST be considered a success. Otherwise, the verificationMUST be considered a failure.¶
If the verification fails or otherwise experiences an error or if any needed parameters are missing, then the verificationMUST 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[RFC9172]. If the security acceptor is not the bundle destination and if no other integrity service is being applied to the target block, then a CRCMUST 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.¶
The BCB-AES-GCM security context replaces the block-type-specific data field of its security target with ciphertext generated using the Advanced Encryption Standard (AES) cipher operating in Galois/Counter Mode (GCM)[AES-GCM]. The use of AES-GCM was selected as the cipher suite for this confidentiality mechanism for several reasons:¶
Additionally, the BCB-AES-GCM security context generates an authentication tag based on the plaintext value of the block-type-specific data and other additional authenticated data (AAD) that might be specified via parameters to this security context.¶
This security context supports two variants of AES-GCM, based on the supported length of the symmetric key. These variants correspond to A128GCM and A256GCM as defined in Table 9 ("Algorithm Value for AES-GCM") of[RFC8152].¶
The BCB-AES-GCM security contextMUST have the security context identifier specified inSection 5.1.¶
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 ciphertext. The second defines the set of information used to generate an authentication tag.¶
The scope of the confidentiality service defines the set of information provided to the AES-GCM cipher for the purpose of producing ciphertext. ThisMUST be the full set of plaintext contained in the block-type-specific data field of the security target.¶
The scope of the authentication service defines the set of information used to generate an authentication tag carried with the security block. This information contains all data protected by the confidentiality service and the scope flags used to identify other optional information; itMAY include other information (additional authenticated data), as follows.¶
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.¶
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.¶
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.¶
BCB-AES-GCM can be parameterized to specify the AES variant, initialization vector, key information, and identify additional authenticated data.¶
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 bytesSHOULD be used unless local security policy requires a different length.¶
This valueMUST be encoded as a CBOR byte string.¶
The initialization vector can have any value, with the caveat that a valueMUST NOT be reused for multiple encryptions using the same encryption key. This valueMAY 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.¶
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 valueMUST be encoded as a CBOR unsigned integer.¶
Valid values for this parameter are as follows.¶
| Value | Description |
|---|---|
| 1 | A128GCM as defined in Table 9 ("Algorithm Value for AES-GCM") of[RFC8152] |
| 3 | A256GCM as defined in Table 9 ("Algorithm Value for AES-GCM") of[RFC8152] |
When not provided, implementationsSHOULD 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 tagMUST always be 128 bits.¶
This optional parameter contains the output of the AES key wrap function as defined in[RFC3394]. Specifically, this parameter holds the ciphertext produced when running this key wrap algorithm with the input string being the symmetric AES key used to generate the security results present in the security block. The value of this parameter is used as input to the AES key wrap authenticated decryption function 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 valueMUST be encoded as a CBOR byte string.¶
If this parameter is not present, then security verifiers and acceptorsMUST determine the proper key as a function of their local BPSec policy and configuration.¶
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 valueMUST be represented as a CBOR unsigned integer, the value of whichMUST be processed as a 16-bit field. The maximum value of this field, as a CBOR unsigned integer,MUST be 65535.¶
When not provided, implementationsSHOULD assume a value of 7 (indicating all assigned fields), unless an alternate default is established by local security policy at the security source, verifier, or acceptor of this integrity service.¶
ImplementationsMUST set reserved and unassigned bits in this field to 0 when constructing these flags at a security source. Once set, the value of this fieldMUST 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.¶
The BCB-AES-GCM security context parameters are listed inTable 5. In this table, the "Parm Id" column refers to the expected parameter identifier described in Section3.10 ("Parameter and Result Identification") of[RFC9172].¶
An empty "Default Value" column indicates that the security context parameter does not have a default value.¶
| 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 |
The BCB-AES-GCM security context produces a single security result carried in the security block: the authentication tag.¶
NOTES:¶
The authentication tag is generated by the cipher suite over the security target plaintext input to the cipher suite as combined with any optional additional authenticated data. This tag is used to ensure that the plaintext (and important information associated with the plaintext) is authenticated prior to decryption.¶
If the authentication tag is included in the ciphertext placed in the security target block-type-specific data field, then this security resultMUST 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 valueMUST be encoded as a CBOR byte string.¶
The BCB-AES-GCM security context results are listed inTable 6. In this table, the "Result Id" column refers to the expected result identifier described in Section3.10 ("Parameter and Result Identification") of[RFC9172].¶
| Result Id | Result Name | CBOR Encoding Type |
|---|---|---|
| 1 | Authentication Tag | byte string |
Keys used with this contextMUST be symmetric andMUST 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.¶
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 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 264, as described in Appendix B of[AES-GCM].¶
Additionally, there exist limits on the number of encryptions that can be performed with the same key. The total number of invocations of the authenticated encryption function with a single key for AES-GCM is required to not exceed 232, as described in Section 8.3 of[AES-GCM].¶
As discussed inSection 6 and emphasized here, it is strongly recommended that keys be protected once generated, both when they are stored and when they are transmitted.¶
The GCM cryptographic mode of AES has specific requirements thatMUST be followed by implementers for the secure function of the BCB-AES-GCM security context. While these requirements are well documented in[AES-GCM], some of them are repeated here for emphasis.¶
With the exception of the AES-KW function, the IVs used by the BCB-AES-GCM security context are considered to be per-invocation IVs. The pairing of a per-invocation IV and a security keyMUST be unique. A per-invocation IVMUST 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). ImplementersSHOULD carefully read all relevant sections of[AES-GCM] when generating any mechanism to create unique IVs.¶
This section defines the canonicalization algorithms used to prepare the inputs used to generate both the ciphertext and the authentication tag.¶
In all cases, the canonical form of any portion of an extension blockMUST be created as described in[RFC9172]. The canonicalization algorithms defined in[RFC9172] adhere to the canonical forms for extension blocks defined in[RFC9171] but resolve ambiguities related to how values are represented in CBOR.¶
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 plaintext used during encryptionMUST be calculated as the value of the block-type-specific data field of the security target excluding the BP CBOR encoding.¶
Table 7 shows two CBOR-encoded examples and the plaintext that would be extracted from them. The first example is an unsigned integer, while the second is a byte string.¶
| CBOR Encoding (Hex) | CBOR Part (Hex) | Plaintext Part (Hex) |
|---|---|---|
| 18ED | 18 | ED |
| C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF |
The ciphertext used during decryptionMUST 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.¶
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, theyMUST be included in the AAD value itself. This processMUST be followed when generating AAD for either encryption or decryption.¶
During encryption, four data elements are prepared for input to the AES-GCM cipher: the encryption key, the IV, the security target plaintext to be encrypted, and any additional authenticated data. These data itemsMUST be generated as follows.¶
Prior to encryption, if a CRC value is present for the target block, then that CRC valueMUST 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."¶
Upon successful encryption, the following actionsMUST occur.¶
Finally, the BCB containing information about this security operationMUST be updated as follows. These operations can occur in any order.¶
Problems encountered in the encryptionMUST be processed in accordance with local security policy. ThisMAY 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.¶
During decryption, five data elements are prepared for input to the AES-GCM cipher: the decryption key, the IV, the security target ciphertext to be decrypted, any additional authenticated data, and the authentication tag generated from the original encryption. These data itemsMUST be generated as follows.¶
Upon successful decryption, the following actionMUST occur.¶
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 CRCMUST 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 ciphertext fails to authenticate, if any needed parameters are missing, or if there are other problems in the decryption, then the decryptionMUST be treated as failed and processed in accordance with local security policy.¶
This specification allocates two security context identifiers from the "BPSec Security Context Identifiers" registry defined in[RFC9172].¶
| Value | Description | Reference |
|---|---|---|
| 1 | BIB-HMAC-SHA2 | RFC 9173 |
| 2 | BCB-AES-GCM | RFC 9173 |
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.Table 9 shows the initial values for this registry.¶
The registration policy for this registry is Specification Required[RFC8126].¶
The value range is unsigned 16-bit integer.¶
| Bit Position (right to left) | Description | Reference |
|---|---|---|
| 0 | Include primary block flag | RFC 9173 |
| 1 | Include target header flag | RFC 9173 |
| 2 | Include security header flag | RFC 9173 |
| 3-7 | Reserved | RFC 9173 |
| 8-15 | Unassigned |
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.Table 10 shows the initial values for this registry.¶
The registration policy for this registry is Specification Required.¶
The value range is unsigned 16-bit integer.¶
| Bit Position (right to left) | Description | Reference |
|---|---|---|
| 0 | Include primary block flag | RFC 9173 |
| 1 | Include target header flag | RFC 9173 |
| 2 | Include security header flag | RFC 9173 |
| 3-7 | Reserved | RFC 9173 |
| 8-15 | Unassigned |
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.¶
Security considerations specific to a single security context are provided in the description of that context (see Sections3 and4). 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.¶
The delayed and disrupted nature of Delay-Tolerant Networking (DTN) 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 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"[RFC9172]. This assumption is also made by the security contexts defined in this document, which do not define new protocols for key derivation, exchange of KEKs, revocation of existing keys, or the security configuration or policy used to select certain keys for certain security operations.¶
Nodes using these security contexts need to perform the following kinds of activities, independent of the construction, transmission, and processing of BPSec security blocks.¶
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.¶
Once generated, keys should be handled as follows.¶
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 inSection 4.6 as part of the documentation of the BCB-AES-GCM security context.¶
The length of the ciphertext produced by the GCM mode of AES will be equal to the length of the plaintext input to the cipher suite. The authentication tag also produced by this cipher suite is separate from the ciphertext. However, it should be noted that implementations of the AES-GCM cipher suite might not separate the concept of ciphertext 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 ciphertext replacing the block-type-specific data field of the target block. ImplementationsMAY use the authentication tag security result in cases where keeping target block length unchanged is an important processing concern. In all cases, the ciphertext and authentication tagMUST be processed in accordance with the API of the AES-GCM cipher suites at the security source and security acceptor.¶
The 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 KEK provided by local security policy at the security verifier or security acceptor.¶
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.¶
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.¶
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 context parameters, security results, or use of security blocks in a bundle.¶
NOTES:¶
This example shows the addition of a BIB to a sample bundle to provide integrity for the payload block.¶
The following diagram shows the original bundle before the BIB has been added.¶
Block Block Block in Bundle Type Number+========================================+=======+========+| Primary Block | N/A | 0 |+----------------------------------------+-------+--------+| Payload Block | 1 | 1 |+----------------------------------------+-------+--------+
The Bundle Protocol version 7 (BPv7) bundle has no special block and bundle processing control flags, and no CRC is provided because the primary block is expected to be protected by an integrity service BIB using the BIB-HMAC-SHA2 security context.¶
The bundle is sourced at the source node ipn:2.1 and destined for the destination node ipn:1.2. The bundle creation time is set to 0, indicating lack of an accurate clock, with a sequence number of 40. The lifetime of the bundle is given as 1,000,000 milliseconds since the bundle creation time.¶
The primary block is provided as follows.¶
[ 7, / BP version / 0, / flags / 0, / CRC type / [2, [1,2]], / destination (ipn:1.2) / [2, [2,1]], / source (ipn:2.1) / [2, [2,1]], / report-to (ipn:2.1) / [0, 40], / timestamp / 1000000 / lifetime /]
The CBOR encoding of the primary block is:¶
0x88070000820282010282028202018202820201820018281a000f4240¶
Other than its use as a source of plaintext for security blocks, the payload has no required distinguishing characteristic for the purpose of this example. The sample payload is a 35-byte string.¶
The payload is represented in the payload block as a byte string of the raw payload string. It is NOT represented as a CBOR text string wrapped within a CBOR binary string. The hex value of the payload is:¶
0x526561647920746f2067656e657261746520612033322d62797465207061796c6f6164¶
The payload block is provided as follows.¶
[ 1, / type code: Payload block / 1, / block number / 0, / block processing control flags / 0, / CRC type / h'526561647920746f206765 / type-specific-data: payload / 6e657261746520612033322d 62797465207061796c6f6164']
The CBOR encoding of the payload block is:¶
0x85010100005823526561647920746f2067656e657261746520612033322d62797465207061796c6f6164¶
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:¶
0x9f88070000820282010282028202018202820201820018281a000f424085010100005823526561647920746f2067656e657261746520612033322d62797465207061796c6f6164ff¶
This example adds a BIB to the bundle using the BIB-HMAC-SHA2 security context to provide an integrity mechanism over the payload block.¶
The following diagram shows the resulting bundle after the BIB is added.¶
Block Block Block in Bundle Type Number+========================================+=======+========+| Primary Block | N/A | 0 |+----------------------------------------+-------+--------+| Block Integrity Block | 11 | 2 || OP(bib-integrity, target=1) | | |+----------------------------------------+-------+--------+| Payload Block | 1 | 1 |+----------------------------------------+-------+--------+
In this example, a BIB is used to carry an integrity signature over the payload block.¶
For this example, the following configuration and security context parameters are used to generate the security results indicated.¶
This BIB has a single target and includes a single security result: the calculated signature over the payload block.¶
Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' SHA Variant : HMAC 512/512 Scope Flags : 0x00 Payload Data: h'526561647920746f2067656e65726174 6520612033322d62797465207061796c 6f6164' IPPT : h'005823526561647920746f2067656e65 7261746520612033322d627974652070 61796c6f6164' Signature : h'3bdc69b3a34a2b5d3a8554368bd1e808 f606219d2a10a846eae3886ae4ecc83c 4ee550fdfb1cc636b904e2f1a73e303d cd4b6ccece003e95e8164dcc89a156e1'
The abstract security block structure of the BIB's block-type-specific data field for this application is as follows.¶
[1], / Security Target - Payload block /1, / Security Context ID - BIB-HMAC-SHA2 /1, / Security Context Flags - Parameters Present /[2,[2, 1]], / Security Source - ipn:2.1 /[ / Security Parameters - 2 Parameters / [1, 7], / SHA Variant - HMAC 512/512 / [3, 0x00] / Scope Flags - No Additional Scope /],[ / Security Results: 1 Result / [ / Target 1 Results / [1, h'3bdc69b3a34a2b5d3a8554368bd1e808 / MAC / f606219d2a10a846eae3886ae4ecc83c 4ee550fdfb1cc636b904e2f1a73e303d cd4b6ccece003e95e8164dcc89a156e1'] ]]
The CBOR encoding of the BIB block-type-specific data field (the abstract security block) is:¶
0x810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1¶
The complete BIB is as follows.¶
[ 11, / type code / 2, / block number / 0, / flags / 0, / CRC type / h'810101018202820201828201078203008181820158403bdc69b3a34a 2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550 fdfb1cc636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1']
The CBOR encoding of the BIB block is:¶
0x850b0200005856810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1¶
The CBOR encoding of the full output bundle, with the BIB:¶
0x9f88070000820282010282028202018202820201820018281a000f4240850b0200005856810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e185010100005823526561647920746f2067656e657261746520612033322d62797465207061796c6f6164ff¶
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.¶
The following diagram shows the original bundle before the BCB has been added.¶
Block Block Block in Bundle Type Number+========================================+=======+========+| Primary Block | N/A | 0 |+----------------------------------------+-------+--------+| Payload Block | 1 | 1 |+----------------------------------------+-------+--------+
The primary block used in this example is identical to the primary block presented for Example 1 inAppendix A.1.1.1.¶
In summary, the CBOR encoding of the primary block is:¶
0x88070000820282010282028202018202820201820018281a000f4240¶
The payload block used in this example is identical to the payload block presented for Example 1 inAppendix A.1.1.2.¶
In summary, the CBOR encoding of the payload block is:¶
0x85010100005823526561647920746f2067656e657261746520612033322d62797465207061796c6f6164¶
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:¶
0x9f88070000820282010282028202018202820201820018281a000f424085010100005823526561647920746f2067656e657261746520612033322d62797465207061796c6f6164ff¶
This example adds a BCB using the BCB-AES-GCM security context using AES key wrap to provide a confidentiality mechanism over the payload block and transmit the symmetric key.¶
The following diagram shows the resulting bundle after the BCB is added.¶
Block Block Block in Bundle Type Number+========================================+=======+========+| Primary Block | N/A | 0 |+----------------------------------------+-------+--------+| Block Confidentiality Block | 12 | 2 || OP(bcb-confidentiality, target=1) | | |+----------------------------------------+-------+--------+| Payload Block (Encrypted) | 1 | 1 |+----------------------------------------+-------+--------+
In this example, a BCB is used to encrypt the payload block, and AES key wrap is used to encode the symmetric key prior to its inclusion in the BCB.¶
For this example, the following configuration and security context parameters are used to generate the security results indicated.¶
This BCB has a single target -- the payload block. Three security results are generated: ciphertext that replaces the plaintext block-type-specific data to encrypt the payload block, an authentication tag, and the AES wrapped key.¶
Content Encryption Key: h'71776572747975696f70617364666768' Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70' IV: h'5477656c7665313231323132' AES Variant: A128GCM AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892 96fabf34d7fae700' Scope Flags: 0x00 Payload Data: h'526561647920746f2067656e65726174 6520612033322d62797465207061796c 6f6164' AAD: h'00' Authentication Tag: h'efa4b5ac0108e3816c5606479801bc04' Payload Ciphertext: h'3a09c1e63fe23a7f66a59c7303837241 e070b02619fc59c5214a22f08cd70795 e73e9a'
The abstract security block structure of the BCB's block-type-specific data field for this application is as follows.¶
[1], / Security Target - Payload block /2, / Security Context ID - BCB-AES-GCM /1, / Security Context Flags - Parameters Present /[2,[2, 1]], / Security Source - ipn:2.1 /[ / Security Parameters - 4 Parameters / [1, h'5477656c7665313231323132'], / Initialization Vector / [2, 1], / AES Variant - A128GCM / [3, h'69c411276fecddc4780df42c8a / AES wrapped key / 2af89296fabf34d7fae700'], [4, 0x00] / Scope Flags - No extra scope/],[ / Security Results: 1 Result / [ / Target 1 Results / [1, h'efa4b5ac0108e3816c5606479801bc04'] / Payload Auth. Tag / ]]
The CBOR encoding of the BCB block-type-specific data field (the abstract security block) is:¶
0x8101020182028202018482014c5477656c76653132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150efa4b5ac0108e3816c5606479801bc04¶
The complete BCB is as follows.¶
[ 12, / type code / 2, / block number / 1, / flags - block must be replicated in every fragment / 0, / CRC type / h'8101020182028202018482014c5477656c766531323132313282020182035818 69c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150 efa4b5ac0108e3816c5606479801bc04']
The CBOR encoding of the BCB block is:¶
0x850c02010058508101020182028202018482014c5477656c76653132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150efa4b5ac0108e3816c5606479801bc04¶
The CBOR encoding of the full output bundle, with the BCB:¶
0x9f88070000820282010282028202018202820201820018281a000f4240850c02010058508101020182028202018482014c5477656c76653132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150efa4b5ac0108e3816c5606479801bc04850101000058233a09c1e63fe23a7f66a59c7303837241e070b02619fc59c5214a22f08cd70795e73e9aff¶
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 block and Bundle Age Block.¶
The following diagram shows the original bundle before the security blocks have been added.¶
Block Block Block in Bundle Type Number+========================================+=======+========+| Primary Block | N/A | 0 |+----------------------------------------+-------+--------+| Extension Block: Bundle Age Block | 7 | 2 |+----------------------------------------+-------+--------+| Payload Block | 1 | 1 |+----------------------------------------+-------+--------+
The primary block used in this example is identical to the primary block presented for Example 1 inAppendix A.1.1.1.¶
In summary, the CBOR encoding of the primary block is:¶
0x88070000820282010282028202018202820201820018281a000f4240¶
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 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.¶
[ 7, / type code: Bundle Age Block / 2, / block number / 0, / block processing control flags / 0, / CRC type / <<300>> / type-specific-data: age /]
The CBOR encoding of the Bundle Age Block is:¶
0x85070200004319012c¶
The payload block used in this example is identical to the payload block presented for Example 1 inAppendix A.1.1.2.¶
In summary, the CBOR encoding of the payload block is:¶
0x85010100005823526561647920746f2067656e657261746520612033322d62797465207061796c6f6164¶
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:¶
0x9f88070000820282010282028202018202820201820018281a000f424085070200004319012c85010100005823526561647920746f2067656e657261746520612033322d62797465207061796c6f6164ff¶
This example provides:¶
The following diagram shows the resulting bundle after the security blocks are added.¶
Block Block Block in Bundle Type Number+========================================+=======+========+| Primary Block | N/A | 0 |+----------------------------------------+-------+--------+| 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 |+----------------------------------------+-------+--------+
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.¶
For this example, the following configuration and security context parameters are used to generate the security results indicated.¶
This BIB has two security targets and includes two security results, holding the calculated signatures over the Bundle Age Block and primary block.¶
Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' SHA Variant: HMAC 256/256 Scope Flags: 0x00 Primary Block Data: h'88070000820282010282028202018202 820201820018281a000f4240' Bundle Age Block Data: h'4319012c' Primary Block IPPT: h'00581c88070000820282010282028202 018202820201820018281a000f4240'Bundle Age Block IPPT: h'004319012c' Primary Block Signature: h'cac6ce8e4c5dae57988b757e49a6dd14 31dc04763541b2845098265bc817241b' Bundle Age Block Signature: h'3ed614c0d97f49b3633627779aa18a33 8d212bf3c92b97759d9739cd50725596'
The abstract security block structure of the BIB's block-type-specific data field for this application is as follows.¶
[0, 2], / Security Targets /1, / Security Context ID - BIB-HMAC-SHA2 /1, / Security Context Flags - Parameters Present /[2,[3, 0]], / Security Source - ipn:3.0 /[ / Security Parameters - 2 Parameters / [1, 5], / SHA Variant - HMAC 256 / [3, 0] / Scope Flags - No Additional Scope /],[ / Security Results: 2 Results / [ / Primary Block Results / [1, h'cac6ce8e4c5dae57988b757e49a6dd14 31dc04763541b2845098265bc817241b'] / MAC / ], [ / Bundle Age Block Results / [1, h'3ed614c0d97f49b3633627779aa18a33 8d212bf3c92b97759d9739cd50725596'] / MAC / ]]
The CBOR encoding of the BIB block-type-specific data field (the abstract security block) is:¶
0x8200020101820282030082820105820300828182015820cac6ce8e4c5dae57988b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d97f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596¶
The complete BIB is as follows.¶
[ 11, / type code / 3, / block number / 0, / flags / 0, / CRC type / h'8200020101820282030082820105820300828182015820cac6ce8e4c5dae5798 8b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9 7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596']
The CBOR encoding of the BIB block is:¶
0x850b030000585c8200020101820282030082820105820300828182015820cac6ce8e4c5dae57988b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d97f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596¶
In this example, a BCB is used encrypt the payload block. The BCB is added by the bundle source node, ipn:2.1.¶
For this example, the following configuration and security context parameters are used to generate the security results indicated.¶
This BCB has a single target, the payload block. Two security results are generated: ciphertext that replaces the plaintext block-type-specific data to encrypt the payload block and an authentication tag.¶
Content Encryption Key: h'71776572747975696f70617364666768' IV: h'5477656c7665313231323132' AES Variant: A128GCM Scope Flags: 0x00 Payload Data: h'526561647920746f2067656e65726174 6520612033322d62797465207061796c 6f6164' AAD: h'00' Authentication Tag: h'efa4b5ac0108e3816c5606479801bc04' Payload Ciphertext: h'3a09c1e63fe23a7f66a59c7303837241 e070b02619fc59c5214a22f08cd70795 e73e9a'
The abstract security block structure of the BCB's block-type-specific data field for this application is as follows.¶
[1], / Security Target - Payload block /2, / Security Context ID - BCB-AES-GCM /1, / Security Context Flags - Parameters Present /[2,[2, 1]], / Security Source - ipn:2.1 /[ / Security Parameters - 3 Parameters / [1, h'5477656c7665313231323132'], / Initialization Vector / [2, 1], / AES Variant - AES 128 / [4, 0] / Scope Flags - No Additional Scope /],[ / Security Results: 1 Result / [ [1, h'efa4b5ac0108e3816c5606479801bc04'] / Payload Auth. Tag / ]]
The CBOR encoding of the BCB block-type-specific data field (the abstract security block) is:¶
0x8101020182028202018382014c5477656c76653132313231328202018204008181820150efa4b5ac0108e3816c5606479801bc04¶
The complete BCB is as follows.¶
[ 12, / type code / 4, / block number / 1, / flags - block must be replicated in every fragment / 0, / CRC type / h'8101020182028202018382014c5477656c766531323132313282020182040081 81820150efa4b5ac0108e3816c5606479801bc04']
The CBOR encoding of the BCB block is:¶
0x850c04010058348101020182028202018382014c5477656c76653132313231328202018204008181820150efa4b5ac0108e3816c5606479801bc04¶
The CBOR encoding of the full output bundle, with the BIB and BCB added is:¶
0x9f88070000820282010282028202018202820201820018281a000f4240850b030000585c8200020101820282030082820105820300828182015820cac6ce8e4c5dae57988b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d97f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596850c04010058348101020182028202018382014c5477656c76653132313231328202018204008181820150efa4b5ac0108e3816c5606479801bc0485070200004319012c850101000058233a09c1e63fe23a7f66a59c7303837241e070b02619fc59c5214a22f08cd70795e73e9aff¶
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.¶
The following diagram shows the original bundle before the security blocks have been added.¶
Block Block Block in Bundle Type Number+========================================+=======+========+| Primary Block | N/A | 0 |+----------------------------------------+-------+--------+| Payload Block | 1 | 1 |+----------------------------------------+-------+--------+
The primary block used in this example is identical to the primary block presented for Example 1 inAppendix A.1.1.1.¶
In summary, the CBOR encoding of the primary block is:¶
0x88070000820282010282028202018202820201820018281a000f4240¶
The payload block used in this example is identical to the payload block presented for Example 1 inAppendix A.1.1.2.¶
In summary, the CBOR encoding of the payload block is:¶
0x85010100005823526561647920746f2067656e657261746520612033322d62797465207061796c6f6164¶
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:¶
0x9f88070000820282010282028202018202820201820018281a000f424085010100005823526561647920746f2067656e657261746520612033322d62797465207061796c6f6164ff¶
This example provides:¶
The following diagram shows the resulting bundle after the security blocks are added.¶
Block Block Block in Bundle Type Number+========================================+=======+========+| Primary Block | N/A | 0 |+----------------------------------------+-------+--------+| 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 |+----------------------------------------+-------+--------+
In this example, a BIB is used to carry an integrity signature over the payload block. The IPPT contains the block-type-specific data of the payload block, the primary block data, the payload block header, and the BIB header. That is, all additional headers are included in the IPPT.¶
For this example, the following configuration and security context parameters are used to generate the security results indicated.¶
This BIB has a single target and includes a single security result: the calculated signature over the Payload block.¶
Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' SHA Variant: HMAC 384/384 Scope Flags: 0x07 (all additional headers)Primary Block Data: h'88070000820282010282028202018202 820201820018281a000f4240' Payload Data: h'526561647920746f2067656e65726174 6520612033322d62797465207061796c 6f6164' Payload Header: h'010100' BIB Header: h'0b0300' IPPT: h'07880700008202820102820282020182 02820201820018281a000f4240010100 0b03005823526561647920746f206765 6e657261746520612033322d62797465 207061796c6f6164' Payload Signature: h'f75fe4c37f76f046165855bd5ff72fbf d4e3a64b4695c40e2b787da005ae819f 0a2e30a2e8b325527de8aefb52e73d71,
The abstract security block structure of the BIB's block-type-specific data field for this application is as follows.¶
[1], / Security Target - Payload block /1, / Security Context ID - BIB-HMAC-SHA2 /1, / Security Context Flags - Parameters Present /[2,[2, 1]], / Security Source - ipn:2.1 /[ / Security Parameters - 2 Parameters / [1, 6], / SHA Variant - HMAC 384/384 / [3, 0x07] / Scope Flags - All additional headers /],[ / Security Results: 1 Result / [ / Target 1 Results / [1, h'f75fe4c37f76f046165855bd5ff72fbf / MAC / d4e3a64b4695c40e2b787da005ae819f 0a2e30a2e8b325527de8aefb52e73d71'] ]]
The CBOR encoding of the BIB block-type-specific data field (the abstract security block) is:¶
0x81010101820282020182820106820307818182015830f75fe4c37f76f046165855bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8aefb52e73d71¶
The complete BIB is as follows.¶
[ 11, / type code / 3, / block number / 0, / flags / 0, / CRC type / h'81010101820282020182820106820307818182015830f75fe4c37f76f0461658 55bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8 aefb52e73d71']
The CBOR encoding of the BIB block is:¶
0x850b030000584681010101820282020182820106820307818182015830f75fe4c37f76f046165855bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8aefb52e73d71¶
In this example, a BCB is used encrypt the payload block and the BIB that provides integrity over the payload.¶
For this example, the following configuration and security context parameters are used to generate the security results indicated.¶
This BCB has two targets: the payload block and BIB. Four security results are generated: ciphertext that replaces the plaintext block-type-specific data of the payload block, ciphertext to encrypt the BIB, and authentication tags for both the payload block and BIB.¶
Key: h'71776572747975696f70617364666768 71776572747975696f70617364666768' IV: h'5477656c7665313231323132' AES Variant: A256GCM Scope Flags: 0x07 (All additional headers) Payload Data: h'526561647920746f2067656e65726174 6520612033322d62797465207061796c 6f6164' BIB Data: h'81010101820282020182820106820307 818182015830f75fe4c37f76f0461658 55bd5ff72fbfd4e3a64b4695c40e2b78 7da005ae819f0a2e30a2e8b325527de8 aefb52e73d71' Primary Block Data: h'88070000820282010282028202018202 820201820018281a000f4240' Payload Header: h'010100' BIB Header: h'0b0300' BCB Header: h'0c0201' Payload AAD: h'07880700008202820102820282020182 02820201820018281a000f4240010100 0c0201' BIB AAD: h'07880700008202820102820282020182 02820201820018281a000f42400b0300 0c0201' Payload BlockAuthentication Tag: h'd2c51cb2481792dae8b21d848cede99b' BIBAuthentication Tag: h'220ffc45c8a901999ecc60991dd78b29'Payload Ciphertext: h'90eab6457593379298a8724e16e61f83 7488e127212b59ac91f8a86287b7d076 30a122' BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0 902902064a2983910c4fb2340790bf42 0a7d1921d5bf7c4721e02ab87a93ab1e 0b75cf62e4948727c8b5dae46ed2af05 439b88029191'
The abstract security block structure of the BCB's block-type-specific data field for this application is as follows.¶
[3, 1], / Security Targets /2, / Security Context ID - BCB-AES-GCM /1, / Security Context Flags - Parameters Present /[2,[2, 1]], / Security Source - ipn:2.1 /[ / Security Parameters - 3 Parameters / [1, h'5477656c7665313231323132'], / Initialization Vector / [2, 3], / AES Variant - AES 256 / [4, 0x07] / Scope Flags - All headers in SHA hash /],[ / Security Results: 2 Results / [ [1, h'220ffc45c8a901999ecc60991dd78b29'] / BIB Auth. Tag / ], [ [1, h'd2c51cb2481792dae8b21d848cede99b'] / Payload Auth. Tag / ]]
The CBOR encoding of the BCB block-type-specific data field (the abstract security block) is:¶
0x820301020182028202018382014c5477656c76653132313231328202038204078281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792dae8b21d848cede99b¶
The complete BCB is as follows.¶
[ 12, / type code / 2, / block number / 1, / flags - block must be replicated in every fragment / 0, / CRC type / h'820301020182028202018382014c5477656c7665313231323132820203820407 8281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792 dae8b21d848cede99b']
The CBOR encoding of the BCB block is:¶
0x850c0201005849820301020182028202018382014c5477656c76653132313231328202038204078281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792dae8b21d848cede99b¶
The CBOR encoding of the full output bundle, with the security blocks added and payload block and BIB encrypted is:¶
0x9f88070000820282010282028202018202820201820018281a000f4240850b0300005846438ed6208eb1c1ffb94d952175167df0902902064a2983910c4fb2340790bf420a7d1921d5bf7c4721e02ab87a93ab1e0b75cf62e4948727c8b5dae46ed2af05439b88029191850c0201005849820301020182028202018382014c5477656c76653132313231328202038204078281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792dae8b21d848cede99b8501010000582390eab6457593379298a8724e16e61f837488e127212b59ac91f8a86287b7d07630a122ff¶
For informational purposes, this section contains an expression of the IPPT and AAD structures using the Concise Data Definition Language (CDDL).¶
NOTES:¶
start = scope / AAD-list / IPPT-list ; satisfy CDDL decodersscope = uint .bits scope-flagsscope-flags = &( has-primary-ctx: 0, has-target-ctx: 1, has-security-ctx: 2,); Encoded as a CBOR sequenceAAD-list = [ AAD-structure]; Encoded as a CBOR sequenceIPPT-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 blockblock-metadata = ( block-type-code: uint, block-number: uint, block-control-flags,)
Amy Alford of the Johns Hopkins University Applied Physics Laboratory contributed useful review and analysis of these security contexts.¶
Brian Sipos kindly provided the CDDL expression inAppendix B.¶