rfc9173v1.txt   rfc9173.txt 
Internet Engineering Task Force (IETF) E. Birrane, III Internet Engineering Task Force (IETF) E. Birrane, III
Request for Comments: 9173 A. White Request for Comments: 9173 A. White
Category: Standards Track S. Heiner Category: Standards Track S. Heiner
ISSN: 2070-1721 JHU/APL ISSN: 2070-1721 JHU/APL
November 2021 December 2021
Bundle Protocol Security Protocol (BPSec) Default Security Contexts Default Security Contexts for Bundle Protocol Security (BPSec)
Abstract Abstract
This document defines default integrity and confidentiality security This document defines default integrity and confidentiality security
contexts that can be used with Bundle Protocol Security Protocol contexts that can be used with Bundle Protocol Security (BPSec)
(BPSec) implementations. These security contexts are intended to be implementations. These security contexts are intended to be used
used both for testing the interoperability of BPSec implementations both for testing the interoperability of BPSec implementations and
and for providing basic security operations when no other security for providing basic security operations when no other security
contexts are defined or otherwise required for a network. contexts are defined or otherwise required for a network.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
skipping to change at line 82 skipping to change at line 82
4.3.2. AES Variant 4.3.2. AES Variant
4.3.3. Wrapped Key 4.3.3. Wrapped Key
4.3.4. AAD Scope Flags 4.3.4. AAD Scope Flags
4.3.5. Enumerations 4.3.5. Enumerations
4.4. Results 4.4. Results
4.4.1. Authentication Tag 4.4.1. Authentication Tag
4.4.2. Enumerations 4.4.2. Enumerations
4.5. Key Considerations 4.5. Key Considerations
4.6. GCM Considerations 4.6. GCM Considerations
4.7. Canonicalization Algorithms 4.7. Canonicalization Algorithms
4.7.1. Calculations Related to Cipher Text 4.7.1. Calculations Related to Ciphertext
4.7.2. Additional Authenticated Data 4.7.2. Additional Authenticated Data
4.8. Processing 4.8. Processing
4.8.1. Encryption 4.8.1. Encryption
4.8.2. Decryption 4.8.2. Decryption
5. IANA Considerations 5. IANA Considerations
5.1. Security Context Identifiers 5.1. Security Context Identifiers
5.2. Integrity Scope Flags 5.2. Integrity Scope Flags
5.3. AAD Scope Flags 5.3. AAD Scope Flags
5.4. Guidance for Designated Experts 5.4. Guidance for Designated Experts
6. Security Considerations 6. Security Considerations
6.1. Key Management 6.1. Key Management
6.2. Key Handling 6.2. Key Handling
6.3. AES GCM 6.3. AES GCM
6.4. AES Key Wrap 6.4. AES Key Wrap
6.5. Bundle Fragmentation 6.5. Bundle Fragmentation
7. Normative References 7. Normative References
Appendix A. Examples Appendix A. Examples
A.1. Example 1: Simple Integrity A.1. Example 1 - Simple Integrity
A.1.1. Original Bundle A.1.1. Original Bundle
A.1.2. Security Operation Overview A.1.2. Security Operation Overview
A.1.3. Bundle Integrity Block A.1.3. Block Integrity Block
A.1.4. Final Bundle A.1.4. Final Bundle
A.2. Example 2: Simple Confidentiality with Key Wrap A.2. Example 2 - Simple Confidentiality with Key Wrap
A.2.1. Original Bundle A.2.1. Original Bundle
A.2.2. Security Operation Overview A.2.2. Security Operation Overview
A.2.3. Bundle Confidentiality Block A.2.3. Block Confidentiality Block
A.2.4. Final Bundle A.2.4. Final Bundle
A.3. Example 3: Security Blocks from Multiple Sources A.3. Example 3 - Security Blocks from Multiple Sources
A.3.1. Original Bundle A.3.1. Original Bundle
A.3.2. Security Operation Overview A.3.2. Security Operation Overview
A.3.3. Bundle Integrity Block A.3.3. Block Integrity Block
A.3.4. Bundle Confidentiality Block A.3.4. Block Confidentiality Block
A.3.5. Final Bundle A.3.5. Final Bundle
A.4. Example 4: Security Blocks with Full Scope A.4. Example 4 - Security Blocks with Full Scope
A.4.1. Original Bundle A.4.1. Original Bundle
A.4.2. Security Operation Overview A.4.2. Security Operation Overview
A.4.3. Bundle Integrity Block A.4.3. Block Integrity Block
A.4.4. Bundle Confidentiality Block A.4.4. Block Confidentiality Block
A.4.5. Final Bundle A.4.5. Final Bundle
Appendix B. CDDL Expression Appendix B. CDDL Expression
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
The Bundle Protocol Security Protocol (BPSec) specification [RFC9172] The Bundle Protocol Security (BPSec) specification [RFC9172] provides
provides inter-bundle integrity and confidentiality operations for inter-bundle integrity and confidentiality operations for networks
networks deploying the Bundle Protocol (BP) [RFC9171]. BPSec defines deploying the Bundle Protocol (BP) [RFC9171]. BPSec defines BP
BP extension blocks to carry security information produced under the extension blocks to carry security information produced under the
auspices of some security context. auspices of some security context.
This document defines two security contexts (one for an integrity This document defines two security contexts (one for an integrity
service and one for a confidentiality service) for populating BPSec service and one for a confidentiality service) for populating BPSec
Block Integrity Blocks (BIBs) and Block Confidentiality Blocks Block Integrity Blocks (BIBs) and Block Confidentiality Blocks
(BCBs). This document assumes familiarity with the concepts and (BCBs). This document assumes familiarity with the concepts and
terminology associated with BP and BPSec, as these security contexts terminology associated with BP and BPSec, as these security contexts
are used with BPSec security blocks and other BP blocks carried are used with BPSec security blocks and other BP blocks carried
within BP bundles. within BP bundles.
skipping to change at line 159 skipping to change at line 159
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Integrity Security Context BIB-HMAC-SHA2 3. Integrity Security Context BIB-HMAC-SHA2
3.1. Overview 3.1. Overview
The BIB-HMAC-SHA2 security context provides a keyed-hash Message The BIB-HMAC-SHA2 security context provides a keyed-hash Message
Authentication Code (MAC) over a set of plain text information. This Authentication Code (MAC) over a set of plaintext information. This
context uses the Secure Hash Algorithm 2 (SHA-2) discussed in [SHS] context uses the Secure Hash Algorithm 2 (SHA-2) discussed in [SHS]
combined with the Hashed Message Authentication Code (HMAC) keyed combined with the Hashed Message Authentication Code (HMAC) keyed
hash discussed in [RFC2104]. The combination of HMAC and SHA-2 as hash discussed in [RFC2104]. The combination of HMAC and SHA-2 as
the integrity mechanism for this security context was selected for the integrity mechanism for this security context was selected for
two reasons: two reasons:
1. The use of symmetric keys allows this security context to be used 1. The use of symmetric keys allows this security context to be used
in places where an asymmetric-key infrastructure (such as a in places where an asymmetric-key infrastructure (such as a
public key infrastructure) might be impractical. public key infrastructure) might be impractical.
skipping to change at line 191 skipping to change at line 191
The output of the HMAC MUST be equal to the size of the SHA2 hashing The output of the HMAC MUST be equal to the size of the SHA2 hashing
function: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits function: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits
for SHA-512. for SHA-512.
The BIB-HMAC-SHA2 security context MUST have the security context The BIB-HMAC-SHA2 security context MUST have the security context
identifier specified in Section 5.1. identifier specified in Section 5.1.
3.2. Scope 3.2. Scope
The scope of BIB-HMAC-SHA2 is the set of information used to produce The scope of BIB-HMAC-SHA2 is the set of information used to produce
the plain text over which a keyed hash is calculated. This plain the plaintext over which a keyed hash is calculated. This plaintext
text is termed the "Integrity-Protected Plain Text (IPPT)". The is termed the "Integrity-Protected Plaintext (IPPT)". The content of
content of the IPPT is constructed as the concatenation of the IPPT is constructed as the concatenation of information whose
information whose integrity is being preserved from the BIB-HMAC-SHA2 integrity is being preserved from the BIB-HMAC-SHA2 security source
security source to its security acceptor. There are five types of to its security acceptor. There are five types of information that
information that can be used in the generation of the IPPT, based on can be used in the generation of the IPPT, based on how broadly the
how broadly the concept of integrity is being applied. These five concept of integrity is being applied. These five types of
types of information, whether they are required, and why they are information, whether they are required, and why they are important
important for integrity are discussed as follows. for integrity are discussed as follows.
Security target contents Security target contents
The contents of the block-type-specific data field of the security The contents of the block-type-specific data field of the security
target MUST be included in the IPPT. Including this information target MUST be included in the IPPT. Including this information
protects the security target data and is considered the minimal, protects the security target data and is considered the minimal,
required set of information for an integrity service on the required set of information for an integrity service on the
security target. security target.
IPPT scope IPPT scope
The determination of which optional types of information were used The determination of which optional types of information were used
when constructing the IPPT MUST, itself, always be included in the when constructing the IPPT MUST always be included in the IPPT.
IPPT. Including this information ensures that the scope of the Including this information ensures that the scope of the IPPT
IPPT construction at a security source matches the scope of the construction at a security source matches the scope of the IPPT
IPPT construction at security verifiers and security acceptors. construction at security verifiers and security acceptors.
Primary block Primary block
The primary block identifies a bundle, and once created, the The primary block identifies a bundle, and once created, the
contents of this block are immutable. Changes to the primary contents of this block are immutable. Changes to the primary
block associated with the security target indicate that the block associated with the security target indicate that the
security target (and BIB) might no longer be in the correct security target (and BIB) might no longer be in the correct
bundle. bundle.
For example, if a security target and associated BIB are copied For example, if a security target and associated BIB are copied
from one bundle to another bundle, the BIB might still contain a from one bundle to another bundle, the BIB might still contain a
verifiable signature for the security target unless information verifiable signature for the security target unless information
associated with the bundle primary block is included in the keyed associated with the bundle primary block is included in the keyed
hash carried by the BIB. hash carried by the BIB.
Including this information in the IPPT protects the integrity of Including this information in the IPPT protects the integrity of
the association of the security target with a specific bundle. the association of the security target with a specific bundle.
Security target other fields Other fields of the security target
The other fields of the security target include block The other fields of the security target include block
identification and processing information. Changing this identification and processing information. Changing this
information changes how the security target is treated by nodes in information changes how the security target is treated by nodes in
the network even when the "user data" of the security target are the network even when the "user data" of the security target are
otherwise unchanged. otherwise unchanged.
For example, if the block processing control flags of a security For example, if the block processing control flags of a security
target are different at a security verifier than they were target are different at a security verifier than they were
originally set at the security source, then the policy for originally set at the security source, then the policy for
handling the security target has been modified. handling the security target has been modified.
Including this information in the IPPT protects the integrity of Including this information in the IPPT protects the integrity of
the policy and identification of the security target data. the policy and identification of the security target data.
BIB other fields Other fields of the BIB
The other fields of the BIB include block identification and The other fields of the BIB include block identification and
processing information. Changing this information changes how the processing information. Changing this information changes how the
BIB is treated by nodes in the network, even when other aspects of BIB is treated by nodes in the network, even when other aspects of
the BIB are unchanged. the BIB are unchanged.
For example, if the block processing control flags of the BIB are For example, if the block processing control flags of the BIB are
different at a security verifier than they were originally set at different at a security verifier than they were originally set at
the security source, then the policy for handling the BIB has been the security source, then the policy for handling the BIB has been
modified. modified.
Including this information in the IPPT protects the integrity of Including this information in the IPPT protects the integrity of
the policy and identification of the security service in the the policy and identification of the security service in the
bundle. bundle.
NOTE: The security context identifier and security context | NOTE: The security context identifier and security context
parameters of the security block are not included in the IPPT | parameters of the security block are not included in the
because these parameters, by definition, are required to verify or | IPPT because these parameters, by definition, are required
accept the security service. Successful verification at security | to verify or accept the security service. Successful
verifiers and security acceptors implies that these parameters | verification at security verifiers and security acceptors
were unchanged since being specified at the security source. This | implies that these parameters were unchanged since being
is the case because keys cannot be reused across security contexts | specified at the security source. This is the case because
and because the integrity scope flags used to define the IPPT are | keys cannot be reused across security contexts and because
included in the IPPT itself. | 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 The scope of the BIB-HMAC-SHA2 security context is configured using
an optional security context parameter. an optional security context parameter.
3.3. Parameters 3.3. Parameters
BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants,
communicate key information, and define the scope of the IPPT. communicate key information, and define the scope of the IPPT.
3.3.1. SHA Variant 3.3.1. SHA Variant
skipping to change at line 311 skipping to change at line 312
Table 1: SHA Variant Parameter Values Table 1: SHA Variant Parameter Values
When not provided, implementations SHOULD assume a value of 6 When not provided, implementations SHOULD assume a value of 6
(indicating use of HMAC 384/384), unless an alternate default is (indicating use of HMAC 384/384), unless an alternate default is
established by local security policy at the security source, established by local security policy at the security source,
verifiers, or acceptor of this integrity service. verifiers, or acceptor of this integrity service.
3.3.2. Wrapped Key 3.3.2. Wrapped Key
This optional parameter contains the output of the AES key wrap This optional parameter contains the output of the AES key wrap
authenticated encryption function (KW-AE) as defined in [RFC5649]. function as defined in [RFC3394]. Specifically, this parameter holds
Specifically, this parameter holds the cipher text produced when the ciphertext produced when running this key wrap algorithm with the
running the KW-AE algorithm with the input string being the symmetric input string being the symmetric HMAC key used to generate the
HMAC key used to generate the security results present in the security results present in the security block. The value of this
security block. The value of this parameter is used as input to the parameter is used as input to the AES key wrap authenticated
AES key wrap authenticated decryption function (KW-AD) at security decryption function at security verifiers and security acceptors to
verifiers and security acceptors to determine the symmetric HMAC key determine the symmetric HMAC key needed for the proper validation of
needed for the proper validation of the security results in the the security results in the security block.
security block.
This value MUST be encoded as a CBOR byte string. This value MUST be encoded as a CBOR byte string.
If this parameter is not present, then security verifiers and If this parameter is not present, then security verifiers and
acceptors MUST determine the proper key as a function of their local acceptors MUST determine the proper key as a function of their local
BPSec policy and configuration. BPSec policy and configuration.
3.3.3. Integrity Scope Flags 3.3.3. Integrity Scope Flags
This optional parameter contains a series of flags that describe what This optional parameter contains a series of flags that describe what
information is to be included with the block-type-specific data when information is to be included with the block-type-specific data when
constructing the IPPT value. constructing the IPPT value.
This value MUST be represented as a CBOR unsigned integer, the value This value MUST be represented as a CBOR unsigned integer, the value
of which MUST be processed as a 16-bit field. The maximum value of of which MUST be processed as a 16-bit field. The maximum value of
this field, as a CBOR unsigned integer, MUST be 65535. this field, as a CBOR unsigned integer, MUST be 65535.
When not provided, implementations SHOULD assume a value of 7
(indicating all assigned fields), unless an alternate default is
established by local security policy at the security source,
verifier, or acceptor of this integrity service.
Implementations MUST set reserved and unassigned bits in this field Implementations MUST set reserved and unassigned bits in this field
to 0 when constructing these flags at a security source. Once set, to 0 when constructing these flags at a security source. Once set,
the value of this field MUST NOT be altered until the security the value of this field MUST NOT be altered until the security
service is completed at the security acceptor in the network and service is completed at the security acceptor in the network and
removed from the bundle. removed from the bundle.
Bits in this field represent additional information to be included Bits in this field represent additional information to be included
when generating an integrity signature over the security target. when generating an integrity signature over the security target.
These bits are defined as follows. These bits are defined as follows.
Bit 0 (the low-order bit, 0x0001): Primary Block Flag Bit 0 (the low-order bit, 0x0001): Include primary block flag
Bit 1 (0x0002): Target Header Flag Bit 1 (0x0002): Include target header flag
Bit 2 (0x0004): Security Header Flag Bit 2 (0x0004): Include security header flag
Bits 3-7: Reserved Bits 3-7: Reserved
Bits 8-15: Unassigned Bits 8-15: Unassigned
| NOTE: When the security target is the primary block, both the
| primary block flag and target header flag MUST be set to 0.
| Setting the primary block flag to 1 in this case would include
| the contents of the primary block twice in the integrity
| calculation. Setting the target header flag to 1 in this case
| has no meaning because the primary block does not have a block
| header.
3.3.4. Enumerations 3.3.4. Enumerations
The BIB-HMAC-SHA2 security context parameters are listed in Table 2. The BIB-HMAC-SHA2 security context parameters are listed in Table 2.
In this table, the "Parm Id" column refers to the expected parameter In this table, the "Parm Id" column refers to the expected parameter
identifier described in Section 3.10 ("Parameter and Result identifier described in Section 3.10 ("Parameter and Result
Identification") of [RFC9172]. Identification") of [RFC9172].
An empty "Default Value" column indicates that the security parameter An empty "Default Value" column indicates that the security context
does not have a default value. parameter does not have a default value.
+=========+=============+====================+===============+ +=========+=============+====================+===============+
| Parm Id | Parm Name | CBOR Encoding Type | Default Value | | Parm Id | Parm Name | CBOR Encoding Type | Default Value |
+=========+=============+====================+===============+ +=========+=============+====================+===============+
| 1 | SHA Variant | unsigned integer | 6 | | 1 | SHA Variant | unsigned integer | 6 |
+---------+-------------+--------------------+---------------+ +---------+-------------+--------------------+---------------+
| 2 | Wrapped Key | Byte String | | | 2 | Wrapped Key | byte string | |
+---------+-------------+--------------------+---------------+ +---------+-------------+--------------------+---------------+
| 3 | Integrity | unsigned integer | 7 | | 3 | Integrity | unsigned integer | 7 |
| | Scope Flags | | | | | Scope Flags | | |
+---------+-------------+--------------------+---------------+ +---------+-------------+--------------------+---------------+
Table 2: BIB-HMAC-SHA2 Security Parameters Table 2: BIB-HMAC-SHA2 Security Context Parameters
3.4. Results 3.4. Results
The BIB-HMAC-SHA2 security context results are listed in Table 3. In The BIB-HMAC-SHA2 security context results are listed in Table 3. In
this table, the "Result Id" column refers to the expected result this table, the "Result Id" column refers to the expected result
identifier described in Section 3.10 ("Parameter and Result identifier described in Section 3.10 ("Parameter and Result
Identification") of [RFC9172]. Identification") of [RFC9172].
+========+==========+===============+======================+ +========+==========+===============+======================+
| Result | Result | CBOR Encoding | Description | | Result | Result | CBOR Encoding | Description |
skipping to change at line 416 skipping to change at line 429
performing an integrity verification can determine the proper HMAC performing an integrity verification can determine the proper HMAC
key to be used. Potential sources of the HMAC key include (but are key to be used. Potential sources of the HMAC key include (but are
not limited to) the following: not limited to) the following:
* Pre-placed keys selected based on local policy. * Pre-placed keys selected based on local policy.
* Keys extracted from material carried in the BIB. * Keys extracted from material carried in the BIB.
* Session keys negotiated via a mechanism external to the BIB. * Session keys negotiated via a mechanism external to the BIB.
When an AES-KW wrapped key is present in a security block, it is When an AES Key Wrap (AES-KW) [RFC3394] wrapped key is present in a
assumed that security verifiers and security acceptors can security block, it is assumed that security verifiers and security
independently determine the key encryption key (KEK) used in the acceptors can independently determine the key encryption key (KEK)
wrapping of the symmetric HMAC key. used in the wrapping of the symmetric HMAC key.
As discussed in Section 6 and emphasized here, it is strongly As discussed in Section 6 and emphasized here, it is strongly
recommended that keys be protected once generated, both when they are recommended that keys be protected once generated, both when they are
stored and when they are transmitted. stored and when they are transmitted.
3.6. Security Processing Considerations 3.6. Security Processing Considerations
An HMAC calculated over the same IPPT with the same key will always An HMAC calculated over the same IPPT with the same key will always
have the same value. This regularity can lead to practical side- have the same value. This regularity can lead to practical side-
channel attacks whereby an attacker could produce known plain text channel attacks whereby an attacker could produce known plaintext,
and a guess at an HMAC tag and observe the behavior of a verifier. guess at an HMAC tag, and observe the behavior of a verifier. With a
With a modest number of trials, a side-channel attack could produce modest number of trials, a side-channel attack could produce an HMAC
an HMAC tag for attacker-provided plain text without the attacker tag for attacker-provided plaintext without the attacker ever knowing
ever knowing the HMAC key. the HMAC key.
A common method of observing the behavior of a verifier is precise A common method of observing the behavior of a verifier is precise
analysis of the timing associated with comparisons. Therefore, one analysis of the timing associated with comparisons. Therefore, one
way to prevent behavior analysis of this type is to ensure that any way to prevent behavior analysis of this type is to ensure that any
comparisons of the supplied and expected authentication tag occur in comparisons of the supplied and expected authentication tag occur in
constant time. constant time.
A constant-time comparison function SHOULD be used for the comparison A constant-time comparison function SHOULD be used for the comparison
of authentication tags by any implementation of this security of authentication tags by any implementation of this security
context. In cases where such a function is difficult or impossible context. In cases where such a function is difficult or impossible
skipping to change at line 457 skipping to change at line 470
3.7. Canonicalization Algorithms 3.7. Canonicalization Algorithms
This section defines the canonicalization algorithm used to prepare This section defines the canonicalization algorithm used to prepare
the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The
construction of the IPPT depends on the settings of the integrity construction of the IPPT depends on the settings of the integrity
scope flags that can be provided as part of customizing the behavior scope flags that can be provided as part of customizing the behavior
of this security context. of this security context.
In all cases, the canonical form of any portion of an extension block In all cases, the canonical form of any portion of an extension block
MUST be performed as described in [RFC9172]. The canonicalization MUST be created as described in [RFC9172]. The canonicalization
algorithms defined in [RFC9172] adhere to the canonical forms for algorithms defined in [RFC9172] adhere to the canonical forms for
extension blocks defined in [RFC9171] but resolve ambiguities related extension blocks defined in [RFC9171] but resolve ambiguities related
to how values are represented in CBOR. to how values are represented in CBOR.
The IPPT is constructed using the following process. While integrity The IPPT is constructed using the following process. While integrity
scope flags might not be included in the BIB representing the scope flags might not be included in the BIB representing the
security operation, they MUST be included in the IPPT value itself. security operation, they MUST be included in the IPPT value itself.
1. The canonical form of the IPPT starts as the CBOR encoding of the 1. The canonical form of the IPPT starts as the CBOR encoding of the
integrity scope flags in which all unset flags, reserved bits, integrity scope flags in which all unset flags, reserved bits,
skipping to change at line 488 skipping to change at line 501
1, then the canonical form of the block type code, block number, 1, then the canonical form of the block type code, block number,
and block processing control flags associated with the security and block processing control flags associated with the security
target MUST be calculated and, in that order, appended to the target MUST be calculated and, in that order, appended to the
IPPT. IPPT.
4. If the security header flag of the integrity scope flags is set 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 to 1, then the canonical form of the block type code, block
number, and block processing control flags associated with the number, and block processing control flags associated with the
BIB MUST be calculated and, in that order, appended to the IPPT. BIB MUST be calculated and, in that order, appended to the IPPT.
5. The canonical form of the security target block-type-specific 5. The canonical form of the security target MUST be calculated and
data MUST be calculated and appended to the IPPT. appended to the IPPT. If the security target is the primary
block, this is the canonical form of the primary block.
Otherwise, this is the canonical form of the block-type-specific
data of the security target.
3.8. Processing 3.8. Processing
3.8.1. Keyed Hash Generation 3.8.1. Keyed Hash Generation
During keyed hash generation, two inputs are prepared for the During keyed hash generation, two inputs are prepared for the
appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These
data items MUST be generated as follows. data items MUST be generated as follows.
* The HMAC key MUST have the appropriate length as required by local * The HMAC key MUST have the appropriate length as required by local
security policy. The key can be generated specifically for this security policy. The key can be generated specifically for this
integrity service, given as part of local security policy, or integrity service, given as part of local security policy, or
through some other key management mechanism as discussed in obtained through some other key management mechanism as discussed
Section 3.5. in Section 3.5.
* Prior to the generation of the IPPT, if a Cyclic Redundancy Check * 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 is present for the target block of the BIB, then that
CRC value MUST be removed from the target block. This involves CRC value MUST be removed from the target block. This involves
both removing the CRC value from the target block and setting the both removing the CRC value from the target block and setting the
CRC type field of the target block to "no CRC is present." CRC type field of the target block to "no CRC is present."
* Once CRC information is removed, the IPPT MUST be generated as * Once CRC information is removed, the IPPT MUST be generated as
discussed in Section 3.7. discussed in Section 3.7.
Upon successful hash generation, the following actions MUST occur. Upon successful hash generation, the following action MUST occur.
* The keyed hash produced by the HMAC/SHA2 variant MUST be added as * The keyed hash produced by the HMAC/SHA2 variant MUST be added as
a security result for the BIB representing the security operation a security result for the BIB representing the security operation
on this security target, as discussed in Section 3.4. on this security target, as discussed in Section 3.4.
Finally, the BIB containing information about this security operation Finally, the BIB containing information about this security operation
MUST be updated as follows. These operations can occur in any order. MUST be updated as follows. These operations can occur in any order.
* The security context identifier for the BIB MUST be set to the * The security context identifier for the BIB MUST be set to the
context identifier for BIB-HMAC-SHA2. context identifier for BIB-HMAC-SHA2.
* Any local flags used to generate the IPPT MUST be placed in the * Any local flags used to generate the IPPT MUST be placed in the
integrity scope flags security parameter for the BIB unless these integrity scope flags security context parameter for the BIB
flags are expected to be correctly configured at security unless these flags are expected to be correctly configured at
verifiers and acceptors in the network. security verifiers and acceptors in the network.
* The HMAC key MAY be included as a security parameter, in which * The HMAC key MAY be included as a security context parameter, in
case it MUST be wrapped using the NIST AES-KW algorithm and the which case it MUST be wrapped using the AES key wrap function as
results of the wrapping added as the wrapped key security defined in [RFC3394] and the results of the wrapping added as the
parameter for the BIB. wrapped key security context parameter for the BIB.
* The SHA variant used by this security context SHOULD be added as * The SHA variant used by this security context SHOULD be added as
the SHA variant security parameter for the BIB if it differs from the SHA variant security context parameter for the BIB if it
the default key length. Otherwise, this parameter MAY be omitted differs from the default key length. Otherwise, this parameter
if doing so provides a useful reduction in message sizes. MAY be omitted if doing so provides a useful reduction in message
sizes.
Problems encountered in the keyed hash generation MUST be processed Problems encountered in the keyed hash generation MUST be processed
in accordance with local BPSec security policy. in accordance with local BPSec security policy.
3.8.2. Keyed Hash Verification 3.8.2. Keyed Hash Verification
During keyed hash verification, the input of the security target and During keyed hash verification, the input of the security target and
an HMAC key are provided to the appropriate HMAC/SHA2 algorithm. an HMAC key are provided to the appropriate HMAC/SHA2 algorithm.
During keyed hash verification, two inputs are prepared for the During keyed hash verification, two inputs are prepared for the
appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These
data items MUST be generated as follows. data items MUST be generated as follows.
* The HMAC key MUST be derived using the wrapped key security * The HMAC key MUST be derived using the wrapped key security
parameter if such a parameter is included in the security context context parameter if such a parameter is included in the security
parameters of the BIB. Otherwise, this key MUST be derived in context parameters of the BIB. Otherwise, this key MUST be
accordance with security policy at the verifying node as discussed derived in accordance with security policy at the verifying node
in Section 3.5. as discussed in Section 3.5.
* The IPPT MUST be generated as discussed in Section 3.7 with the * The IPPT MUST be generated as discussed in Section 3.7 with the
value of integrity scope flags being taken from the integrity value of integrity scope flags being taken from the integrity
scope flags security context parameter. If the integrity scope scope flags security context parameter. If the integrity scope
flags parameter is not included in the security context flags parameter is not included in the security context
parameters, then these flags MAY be derived from local security parameters, then these flags MAY be derived from local security
policy. policy.
The calculated HMAC output MUST be compared to the expected HMAC The calculated HMAC output MUST be compared to the expected HMAC
output encoded in the security results of the BIB for the security output encoded in the security results of the BIB for the security
skipping to change at line 589 skipping to change at line 606
integrity service is being applied to the target block, then a CRC integrity service is being applied to the target block, then a CRC
MUST be included for the target block. The CRC type, as determined MUST be included for the target block. The CRC type, as determined
by policy, is set in the target block's CRC type field, and the 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. corresponding CRC value is added as the CRC field for that block.
4. Security Context BCB-AES-GCM 4. Security Context BCB-AES-GCM
4.1. Overview 4.1. Overview
The BCB-AES-GCM security context replaces the block-type-specific The BCB-AES-GCM security context replaces the block-type-specific
data field of its security target with cipher text generated using data field of its security target with ciphertext generated using the
the Advanced Encryption Standard (AES) cipher operating in Galois/ Advanced Encryption Standard (AES) cipher operating in Galois/Counter
Counter Mode (GCM) [AES-GCM]. The use of AES-GCM was selected as the Mode (GCM) [AES-GCM]. The use of AES-GCM was selected as the cipher
cipher suite for this confidentiality mechanism for several reasons: suite for this confidentiality mechanism for several reasons:
1. The selection of a symmetric-key cipher suite allows for 1. The selection of a symmetric-key cipher suite allows for
relatively smaller keys than asymmetric-key cipher suites. relatively smaller keys than asymmetric-key cipher suites.
2. The selection of a symmetric-key cipher suite allows this 2. The selection of a symmetric-key cipher suite allows this
security context to be used in places where an asymmetric-key security context to be used in places where an asymmetric-key
infrastructure (such as a public key infrastructure) might be infrastructure (such as a public key infrastructure) might be
impractical. impractical.
3. The use of the Galois/Counter Mode produces cipher text with the 3. The use of the Galois/Counter Mode produces ciphertext with the
same size as the plain text making the replacement of target same size as the plaintext making the replacement of target block
block information easier as length fields do not need to be information easier as length fields do not need to be changed.
changed.
4. The AES-GCM cipher suite provides authenticated encryption, as 4. The AES-GCM cipher suite provides authenticated encryption, as
required by the BPSec protocol. required by the BPSec protocol.
Additionally, the BCB-AES-GCM security context generates an Additionally, the BCB-AES-GCM security context generates an
authentication tag based on the plain text value of the block-type- authentication tag based on the plaintext value of the block-type-
specific data and other additional authenticated data (AAD) that specific data and other additional authenticated data (AAD) that
might be specified via parameters to this security context. might be specified via parameters to this security context.
This security context supports two variants of AES-GCM, based on the This security context supports two variants of AES-GCM, based on the
supported length of the symmetric key. These variants correspond to supported length of the symmetric key. These variants correspond to
A128GCM and A256GCM as defined in Table 9 ("Algorithm Value for AES- A128GCM and A256GCM as defined in Table 9 ("Algorithm Value for AES-
GCM") of [RFC8152]. GCM") of [RFC8152].
The BCB-AES-GCM security context MUST have the security context The BCB-AES-GCM security context MUST have the security context
identifier specified in Section 5.1. identifier specified in Section 5.1.
4.2. Scope 4.2. Scope
There are two scopes associated with BCB-AES-GCM: the scope of the There are two scopes associated with BCB-AES-GCM: the scope of the
confidentiality service and the scope of the authentication service. confidentiality service and the scope of the authentication service.
The first defines the set of information provided to the AES-GCM The first defines the set of information provided to the AES-GCM
cipher for the purpose of producing cipher text. The second defines cipher for the purpose of producing ciphertext. The second defines
the set of information used to generate an authentication tag. the set of information used to generate an authentication tag.
The scope of the confidentiality service defines the set of The scope of the confidentiality service defines the set of
information provided to the AES-GCM cipher for the purpose of information provided to the AES-GCM cipher for the purpose of
producing cipher text. This MUST be the full set of plain text producing ciphertext. This MUST be the full set of plaintext
contained in the block-type-specific data field of the security contained in the block-type-specific data field of the security
target. target.
The scope of the authentication service defines the set of The scope of the authentication service defines the set of
information used to generate an authentication tag carried with the information used to generate an authentication tag carried with the
security block. This information contains all data protected by the security block. This information contains all data protected by the
confidentiality service and the scope flags used to identify other confidentiality service and the scope flags used to identify other
optional information; it MAY include other information (additional optional information; it MAY include other information (additional
authenticated data), as follows. authenticated data), as follows.
skipping to change at line 661 skipping to change at line 677
For example, if a security target and associated BCB are copied For example, if a security target and associated BCB are copied
from one bundle to another bundle, the BCB might still be able to from one bundle to another bundle, the BCB might still be able to
decrypt the security target even though these blocks were never decrypt the security target even though these blocks were never
intended to exist in the copied-to bundle. intended to exist in the copied-to bundle.
Including this information as part of additional authenticated Including this information as part of additional authenticated
data ensures that the security target (and security block) appear data ensures that the security target (and security block) appear
in the same bundle at the time of decryption as at the time of in the same bundle at the time of decryption as at the time of
encryption. encryption.
Security target other fields Other fields of the security target
The other fields of the security target include block The other fields of the security target include block
identification and processing information. Changing this identification and processing information. Changing this
information changes how the security target is treated by nodes in information changes how the security target is treated by nodes in
the network even when the "user data" of the security target are the network even when the "user data" of the security target are
otherwise unchanged. otherwise unchanged.
For example, if the block processing control flags of a security For example, if the block processing control flags of a security
target are different at a security verifier than they were target are different at a security verifier than they were
originally set at the security source, then the policy for originally set at the security source, then the policy for
handling the security target has been modified. handling the security target has been modified.
Including this information as part of additional authenticated Including this information as part of additional authenticated
data ensures that the cipher text in the security target will not data ensures that the ciphertext in the security target will not
be used with a different set of block policy than originally set be used with a different set of block policy than originally set
at the time of encryption. at the time of encryption.
BCB other fields Other fields of the BCB
The other fields of the BCB include block identification and The other fields of the BCB include block identification and
processing information. Changing this information changes how the processing information. Changing this information changes how the
BCB is treated by nodes in the network, even when other aspects of BCB is treated by nodes in the network, even when other aspects of
the BCB are unchanged. the BCB are unchanged.
For example, if the block processing control flags of the BCB are For example, if the block processing control flags of the BCB are
different at a security acceptor than they were originally set at different at a security acceptor than they were originally set at
the security source, then the policy for handling the BCB has been the security source, then the policy for handling the BCB has been
modified. modified.
Including this information as part of additional authenticated Including this information as part of additional authenticated
data ensures that the policy and identification of the security data ensures that the policy and identification of the security
service in the bundle has not changed. service in the bundle has not changed.
NOTE: The security context identifier and security context | NOTE: The security context identifier and security context
parameters of the security block are not included as additional | parameters of the security block are not included as
authenticated data because these parameters, by definition, are | additional authenticated data because these parameters, by
those needed to verify or accept the security service. Therefore, | definition, are those needed to verify or accept the
it is expected that changes to these values would result in | security service. Therefore, it is expected that changes to
failures at security verifiers and security acceptors. This is | these values would result in failures at security verifiers
the case because keys cannot be reused across security contexts | and security acceptors. This is the case because keys
and because the AAD scope flags used to identify the AAD are | cannot be reused across security contexts and because the
included in the AAD. | 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 The scope of the BCB-AES-GCM security context is configured using an
optional security context parameter. optional security context parameter.
4.3. Parameters 4.3. Parameters
BCB-AES-GCM can be parameterized to specify the AES variant, BCB-AES-GCM can be parameterized to specify the AES variant,
initialization vector, key information, and identify additional initialization vector, key information, and identify additional
authenticated data. authenticated data.
skipping to change at line 762 skipping to change at line 779
(indicating use of A256GCM), unless an alternate default is (indicating use of A256GCM), unless an alternate default is
established by local security policy at the security source, established by local security policy at the security source,
verifier, or acceptor of this integrity service. verifier, or acceptor of this integrity service.
Regardless of the variant, the generated authentication tag MUST Regardless of the variant, the generated authentication tag MUST
always be 128 bits. always be 128 bits.
4.3.3. Wrapped Key 4.3.3. Wrapped Key
This optional parameter contains the output of the AES key wrap This optional parameter contains the output of the AES key wrap
authenticated encryption function (KW-AE) as defined in [RFC5649]. function as defined in [RFC3394]. Specifically, this parameter holds
Specifically, this parameter holds the cipher text produced when the ciphertext produced when running this key wrap algorithm with the
running the KW-AE algorithm with the input string being the symmetric input string being the symmetric AES key used to generate the
AES key used to generate the security results present in the security security results present in the security block. The value of this
block. The value of this parameter is used as input to the AES key parameter is used as input to the AES key wrap authenticated
wrap authenticated decryption function (KW-AD) at security verifiers decryption function at security verifiers and security acceptors to
and security acceptors to determine the symmetric AES key needed for determine the symmetric AES key needed for the proper decryption of
the proper decryption of the security results in the security block. the security results in the security block.
This value MUST be encoded as a CBOR byte string. This value MUST be encoded as a CBOR byte string.
If this parameter is not present, then security verifiers and If this parameter is not present, then security verifiers and
acceptors MUST determine the proper key as a function of their local acceptors MUST determine the proper key as a function of their local
BPSec policy and configuration. BPSec policy and configuration.
4.3.4. AAD Scope Flags 4.3.4. AAD Scope Flags
This optional parameter contains a series of flags that describe what This optional parameter contains a series of flags that describe what
information is to be included with the block-type-specific data of information is to be included with the block-type-specific data of
the security target as part of additional authenticated data (AAD). the security target as part of additional authenticated data (AAD).
This value MUST be represented as a CBOR unsigned integer, the value This value MUST be represented as a CBOR unsigned integer, the value
of which MUST be processed as a 16-bit field. The maximum value of of which MUST be processed as a 16-bit field. The maximum value of
this field, as a CBOR unsigned integer, MUST be 65535. this field, as a CBOR unsigned integer, MUST be 65535.
When not provided, implementations SHOULD assume a value of 7
(indicating all assigned fields), unless an alternate default is
established by local security policy at the security source,
verifier, or acceptor of this integrity service.
Implementations MUST set reserved and unassigned bits in this field Implementations MUST set reserved and unassigned bits in this field
to 0 when constructing these flags at a security source. Once set, to 0 when constructing these flags at a security source. Once set,
the value of this field MUST NOT be altered until the security the value of this field MUST NOT be altered until the security
service is completed at the security acceptor in the network and service is completed at the security acceptor in the network and
removed from the bundle. removed from the bundle.
Bits in this field represent additional information to be included Bits in this field represent additional information to be included
when generating an integrity signature over the security target. when generating an integrity signature over the security target.
These bits are defined as follows. These bits are defined as follows.
Bit 0 (the low-order bit, 0x0001): Primary Block Flag Bit 0 (the low-order bit, 0x0001): Include primary block flag
Bit 1 (0x0002): Target Header Flag Bit 1 (0x0002): Include target header flag
Bit 2 (0x0004): Security Header Flag Bit 2 (0x0004): Include security header flag
Bits 3-7: Reserved Bits 3-7: Reserved
Bits 8-15: Unassigned Bits 8-15: Unassigned
4.3.5. Enumerations 4.3.5. Enumerations
The BCB-AES-GCM security context parameters are listed in Table 5. The BCB-AES-GCM security context parameters are listed in Table 5.
In this table, the "Parm Id" column refers to the expected parameter In this table, the "Parm Id" column refers to the expected parameter
identifier described in Section 3.10 ("Parameter and Result identifier described in Section 3.10 ("Parameter and Result
Identification") of [RFC9172]. Identification") of [RFC9172].
An empty "Default Value" column indicates that the security parameter An empty "Default Value" column indicates that the security context
does not have a default value. parameter does not have a default value.
+=========+================+====================+===============+ +=========+================+====================+===============+
| Parm Id | Parm Name | CBOR Encoding Type | Default Value | | Parm Id | Parm Name | CBOR Encoding Type | Default Value |
+=========+================+====================+===============+ +=========+================+====================+===============+
| 1 | Initialization | Byte String | | | 1 | Initialization | byte string | |
| | Vector | | | | | Vector | | |
+---------+----------------+--------------------+---------------+ +---------+----------------+--------------------+---------------+
| 2 | AES Variant | Unsigned Integer | 3 | | 2 | AES Variant | unsigned integer | 3 |
+---------+----------------+--------------------+---------------+ +---------+----------------+--------------------+---------------+
| 3 | Wrapped Key | Byte String | | | 3 | Wrapped Key | byte string | |
+---------+----------------+--------------------+---------------+ +---------+----------------+--------------------+---------------+
| 4 | AAD Scope | Unsigned Integer | 7 | | 4 | AAD Scope | unsigned integer | 7 |
| | Flags | | | | | Flags | | |
+---------+----------------+--------------------+---------------+ +---------+----------------+--------------------+---------------+
Table 5: BCB-AES-GCM Security Parameters Table 5: BCB-AES-GCM Security Context Parameters
4.4. Results 4.4. Results
The BCB-AES-GCM security context produces a single security result The BCB-AES-GCM security context produces a single security result
carried in the security block: the authentication tag. carried in the security block: the authentication tag.
NOTES: NOTES:
* The cipher text generated by the cipher suite is not considered a * The ciphertext generated by the cipher suite is not considered a
security result as it is stored in the block-type-specific data security result as it is stored in the block-type-specific data
field of the security target block. When operating in GCM mode, field of the security target block. When operating in GCM mode,
AES produces cipher text of the same size as its plain text; AES produces ciphertext of the same size as its plaintext;
therefore, no additional logic is required to handle padding or therefore, no additional logic is required to handle padding or
overflow caused by the encryption in most cases (see below). overflow caused by the encryption in most cases.
* If the authentication tag can be separated from the cipher text, * If the authentication tag can be separated from the ciphertext,
then the tag MAY be separated and stored in the authentication tag then the tag MAY be separated and stored in the authentication tag
security result field. Otherwise, the security target block MUST security result field. Otherwise, the security target block MUST
be resized to accommodate the additional 128 bits of be resized to accommodate the additional 128 bits of
authentication tag included with the generated cipher text authentication tag included with the generated ciphertext
replacing the block-type-specific-data field of the security replacing the block-type-specific data field of the security
target block. target block.
4.4.1. Authentication Tag 4.4.1. Authentication Tag
The authentication tag is generated by the cipher suite over the The authentication tag is generated by the cipher suite over the
security target plain text input to the cipher suite as combined with security target plaintext input to the cipher suite as combined with
any optional additional authenticated data. This tag is used to any optional additional authenticated data. This tag is used to
ensure that the plain text (and important information associated with ensure that the plaintext (and important information associated with
the plain text) is authenticated prior to decryption. the plaintext) is authenticated prior to decryption.
If the authentication tag is included in the cipher text placed in If the authentication tag is included in the ciphertext placed in the
the security target block-type-specific data field, then this security target block-type-specific data field, then this security
security result MUST NOT be included in the BCB for that security result MUST NOT be included in the BCB for that security target.
target.
The length of the authentication tag, prior to any CBOR encoding, The length of the authentication tag, prior to any CBOR encoding,
MUST be 128 bits. MUST be 128 bits.
This value MUST be encoded as a CBOR byte string. This value MUST be encoded as a CBOR byte string.
4.4.2. Enumerations 4.4.2. Enumerations
The BCB-AES-GCM security context results are listed in Table 6. In The BCB-AES-GCM security context results are listed in Table 6. In
this table, the "Result Id" column refers to the expected result this table, the "Result Id" column refers to the expected result
identifier described in Section 3.10 ("Parameter and Result identifier described in Section 3.10 ("Parameter and Result
Identification") of [RFC9172]. Identification") of [RFC9172].
+===========+====================+====================+ +===========+====================+====================+
| Result Id | Result Name | CBOR Encoding Type | | Result Id | Result Name | CBOR Encoding Type |
+===========+====================+====================+ +===========+====================+====================+
| 1 | Authentication Tag | Byte String | | 1 | Authentication Tag | byte string |
+-----------+--------------------+--------------------+ +-----------+--------------------+--------------------+
Table 6: BCB-AES-GCM Security Results Table 6: BCB-AES-GCM Security Results
4.5. Key Considerations 4.5. Key Considerations
Keys used with this context MUST be symmetric and MUST have a key Keys used with this context MUST be symmetric and MUST have a key
length equal to the key length defined in the security context length equal to the key length defined in the security context
parameters or as defined by local security policy at security parameters or as defined by local security policy at security
verifiers and acceptors. For this reason, content-encrypting key verifiers and acceptors. For this reason, content-encrypting key
skipping to change at line 909 skipping to change at line 930
include (but are not limited to) the following. include (but are not limited to) the following.
* Pre-placed keys selected based on local policy. * Pre-placed keys selected based on local policy.
* Keys extracted from material carried in the BCB. * Keys extracted from material carried in the BCB.
* Session keys negotiated via a mechanism external to the BCB. * Session keys negotiated via a mechanism external to the BCB.
When an AES-KW wrapped key is present in a security block, it is When an AES-KW wrapped key is present in a security block, it is
assumed that security verifiers and security acceptors can assumed that security verifiers and security acceptors can
independently determine the key encryption key (KEK) used in the independently determine the KEK used in the wrapping of the symmetric
wrapping of the symmetric AES content-encrypting key. AES content-encrypting key.
The security provided by block ciphers is reduced as more data is 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 the same key. The total number of AES blocks
processed with a single key for AES-GCM is recommended to be less processed with a single key for AES-GCM is recommended to be less
than 2^64, as described in Appendix B of [AES-GCM]. than 2^64, as described in Appendix B of [AES-GCM].
Additionally, there exist limits on the number of encryptions that Additionally, there exist limits on the number of encryptions that
can be performed with the same key. The total number of invocations can be performed with the same key. The total number of invocations
of the authenticated encryption function with a single key for AES- of the authenticated encryption function with a single key for AES-
GCM is required to not exceed 2^32, as described in Section 8.3 of GCM is required to not exceed 2^32, as described in Section 8.3 of
skipping to change at line 985 skipping to change at line 1006
* As discussed in Section 8 ("Security Considerations") of * As discussed in Section 8 ("Security Considerations") of
[RFC9172], delay-tolerant networks have a higher occurrence of [RFC9172], delay-tolerant networks have a higher occurrence of
replay attacks due to the store-and-forward nature of the network. replay attacks due to the store-and-forward nature of the network.
Because GCM has no inherent replay attack protection, implementors Because GCM has no inherent replay attack protection, implementors
SHOULD attempt to detect replay attacks by using mechanisms such SHOULD attempt to detect replay attacks by using mechanisms such
as those described in Appendix D of [AES-GCM]. as those described in Appendix D of [AES-GCM].
4.7. Canonicalization Algorithms 4.7. Canonicalization Algorithms
This section defines the canonicalization algorithms used to prepare This section defines the canonicalization algorithms used to prepare
the inputs used to generate both the cipher text and the the inputs used to generate both the ciphertext and the
authentication tag. authentication tag.
In all cases, the canonical form of any portion of an extension block In all cases, the canonical form of any portion of an extension block
MUST be performed as described in [RFC9172]. The canonicalization MUST be created as described in [RFC9172]. The canonicalization
algorithms defined in [RFC9172] adhere to the canonical forms for algorithms defined in [RFC9172] adhere to the canonical forms for
extension blocks defined in [RFC9171] but resolve ambiguities related extension blocks defined in [RFC9171] but resolve ambiguities related
to how values are represented in CBOR. to how values are represented in CBOR.
4.7.1. Calculations Related to Cipher Text 4.7.1. Calculations Related to Ciphertext
The BCB operates over the block-type-specific data of a block, but The BCB operates over the block-type-specific data of a block, but
the BP always encodes these data within a single, definite-length the BP always encodes these data within a single, definite-length
CBOR byte string. Therefore, the plain text used during encryption CBOR byte string. Therefore, the plaintext used during encryption
MUST be calculated as the value of the block-type-specific data field MUST be calculated as the value of the block-type-specific data field
of the security target excluding the BP CBOR encoding. of the security target excluding the BP CBOR encoding.
Table 7 shows two CBOR-encoded examples and the plain text that would Table 7 shows two CBOR-encoded examples and the plaintext that would
be extracted from them. The first example is an unsigned integer, be extracted from them. The first example is an unsigned integer,
while the second is a byte string. while the second is a byte string.
+==============================+=======+==========================+ +==============================+=======+==========================+
| CBOR Encoding (Hex) | CBOR | Plain Text Part (Hex) | | CBOR Encoding (Hex) | CBOR | Plaintext Part (Hex) |
| | Part | | | | Part | |
| | (Hex) | | | | (Hex) | |
+==============================+=======+==========================+ +==============================+=======+==========================+
| 18ED | 18 | ED | | 18ED | 18 | ED |
+------------------------------+-------+--------------------------+ +------------------------------+-------+--------------------------+
| C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF | | C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF |
+------------------------------+-------+--------------------------+ +------------------------------+-------+--------------------------+
Table 7: CBOR Plain Text Extraction Examples Table 7: CBOR Plaintext Extraction Examples
Similarly, the cipher text used during decryption MUST be calculated The ciphertext used during decryption MUST be calculated as the
as the single, definite-length CBOR byte string representing the single, definite-length CBOR byte string representing the block-type-
block-type-specific data field excluding the CBOR byte string specific data field excluding the CBOR byte string identifying byte
identifying byte and optional CBOR byte string length field. and optional CBOR byte string length field.
All other fields of the security target (such as the block type code, All other fields of the security target (such as the block type code,
block number, block processing control flags, or any CRC information) block number, block processing control flags, or any CRC information)
MUST NOT be considered as part of encryption or decryption. MUST NOT be considered as part of encryption or decryption.
4.7.2. Additional Authenticated Data 4.7.2. Additional Authenticated Data
The construction of additional authenticated data depends on the AAD The construction of additional authenticated data depends on the AAD
scope flags that can be provided as part of customizing the behavior scope flags that can be provided as part of customizing the behavior
of this security context. of this security context.
skipping to change at line 1065 skipping to change at line 1086
4. If the security header flag of the AAD scope flags is set to 1, 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 then the canonical form of the block type code, block number, and
block processing control flags associated with the BIB MUST be block processing control flags associated with the BIB MUST be
calculated and, in that order, appended to the AAD. calculated and, in that order, appended to the AAD.
4.8. Processing 4.8. Processing
4.8.1. Encryption 4.8.1. Encryption
During encryption, four inputs are prepared for input to the AES/GCM During encryption, four data elements are prepared for input to the
cipher: the encryption key, the IV, the security target plain text to AES-GCM cipher: the encryption key, the IV, the security target
be encrypted, and any additional authenticated data. These data plaintext to be encrypted, and any additional authenticated data.
items MUST be generated as follows. These data items MUST be generated as follows.
Prior to encryption, if a CRC value is present for the target block, Prior to encryption, if a CRC value is present for the target block,
then that CRC value MUST be removed. This requires removing the CRC then that CRC value MUST be removed. This requires removing the CRC
field from the target block and setting the CRC type field of the field from the target block and setting the CRC type field of the
target block to "no CRC is present." target block to "no CRC is present."
* The encryption key MUST have the appropriate length as required by * The encryption key MUST have the appropriate length as required by
local security policy. The key might be generated specifically local security policy. The key might be generated specifically
for this encryption, given as part of local security policy, or for this encryption, given as part of local security policy, or
through some other key management mechanism as discussed in obtained through some other key management mechanism as discussed
Section 4.5. in Section 4.5.
* The IV selected MUST be of the appropriate length. Because * The IV selected MUST be of the appropriate length. Because
replaying an IV in counter mode voids the confidentiality of all replaying an IV in counter mode voids the confidentiality of all
messages encrypted with said IV, this context also requires a messages encrypted with said IV, this context also requires a
unique IV for every encryption performed with the same key. This unique IV for every encryption performed with the same key. This
means the same key and IV combination MUST NOT be used more than means the same key and IV combination MUST NOT be used more than
once. once.
* The security target plain text for encryption MUST be generated as * The security target plaintext for encryption MUST be generated as
discussed in Section 4.7.1. discussed in Section 4.7.1.
* Additional authenticated data MUST be generated as discussed in * Additional authenticated data MUST be generated as discussed in
Section 4.7.2, with the value of AAD scope flags being taken from Section 4.7.2, with the value of AAD scope flags being taken from
local security policy. local security policy.
Upon successful encryption, the following actions MUST occur. Upon successful encryption, the following actions MUST occur.
* The cipher text produced by AES/GCM MUST replace the bytes used to * The ciphertext produced by AES-GCM MUST replace the bytes used to
define the plain text in the security target block's block-type- define the plaintext in the security target block's block-type-
specific data field. The block length of the security target MUST specific data field. The block length of the security target MUST
be updated if the generated cipher text is larger than the plain be updated if the generated ciphertext is larger than the
text (which can occur when the authentication tag is included in plaintext (which can occur when the authentication tag is included
the cipher text calculation, as discussed in Section 4.4). in the ciphertext calculation, as discussed in Section 4.4).
* The authentication tag calculated by the AES/GCM cipher MAY be * The authentication tag calculated by the AES-GCM cipher MAY be
added as a security result for the security target in the BCB added as a security result for the security target in the BCB
holding results for this security operation, in which case it MUST holding results for this security operation, in which case it MUST
be processed as described in Section 4.4. be processed as described in Section 4.4.
* The authentication tag MUST be included either as a security * The authentication tag MUST be included either as a security
result in the BCB representing the security operation or (with the result in the BCB representing the security operation or (with the
cipher text) in the security target block-type-specific data ciphertext) in the security target block-type-specific data field.
field.
Finally, the BCB containing information about this security operation Finally, the BCB containing information about this security operation
MUST be updated as follows. These operations can occur in any order. MUST be updated as follows. These operations can occur in any order.
* The security context identifier for the BCB MUST be set to the * The security context identifier for the BCB MUST be set to the
context identifier for BCB-AES-GCM. context identifier for BCB-AES-GCM.
* The IV input to the cipher MUST be added as the IV security * The IV input to the cipher MUST be added as the IV security
parameter for the BCB. context parameter for the BCB.
* Any local flags used to generate AAD for this cipher MUST be * Any local flags used to generate AAD for this cipher MUST be
placed in the AAD scope flags security parameter for the BCB placed in the AAD scope flags security context parameter for the
unless these flags are expected to be correctly configured at BCB unless these flags are expected to be correctly configured at
security verifiers and security acceptors in the network. security verifiers and security acceptors in the network.
* The encryption key MAY be included as a security parameter, in * The encryption key MAY be included as a security context
which case it MUST be wrapped using the NIST AES-KW algorithm and parameter, in which case it MUST be wrapped using the AES key wrap
the results of the wrapping added as the wrapped key security function as defined in [RFC3394] and the results of the wrapping
parameter for the BCB. 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 used by this security context SHOULD be added as
the AES variant security parameter for the BCB if it differs from the AES variant security context parameter for the BCB if it
the default key length. Otherwise, this parameter MAY be omitted differs from the default key length. Otherwise, this parameter
if doing so provides a useful reduction in message sizes. MAY be omitted if doing so provides a useful reduction in message
sizes.
Problems encountered in the encryption MUST be processed in Problems encountered in the encryption MUST be processed in
accordance with local security policy. This MAY include restoring a accordance with local security policy. This MAY include restoring a
CRC value removed from the target block prior to encryption, if the CRC value removed from the target block prior to encryption, if the
target block is allowed to be transmitted after an encryption error. target block is allowed to be transmitted after an encryption error.
4.8.2. Decryption 4.8.2. Decryption
During decryption, five inputs are prepared for input to the AES/GCM During decryption, five data elements are prepared for input to the
cipher: the decryption key, the IV, the security target cipher text AES-GCM cipher: the decryption key, the IV, the security target
to be decrypted, any additional authenticated data, and the ciphertext to be decrypted, any additional authenticated data, and
authentication tag generated from the original encryption. These the authentication tag generated from the original encryption. These
data items MUST be generated as follows. data items MUST be generated as follows.
* The decryption key MUST be derived using the wrapped key security * The decryption key MUST be derived using the wrapped key security
parameter if such a parameter is included in the security context context parameter if such a parameter is included in the security
parameters of the BCB. Otherwise, this key MUST be derived in context parameters of the BCB. Otherwise, this key MUST be
accordance with local security policy at the decrypting node as derived in accordance with local security policy at the decrypting
discussed in Section 4.5. node as discussed in Section 4.5.
* The IV MUST be set to the value of the IV security parameter * The IV MUST be set to the value of the IV security context
included in the BCB. If the IV parameter is not included as a parameter included in the BCB. If the IV parameter is not
security parameter, an IV MAY be derived as a function of local included as a security context parameter, an IV MAY be derived as
security policy and other BCB contents, or a lack of an IV a function of local security policy and other BCB contents, or a
security parameter in the BCB MAY be treated as an error by the lack of an IV security context parameter in the BCB MAY be treated
decrypting node. as an error by the decrypting node.
* The security target cipher text for decryption MUST be generated * The security target ciphertext for decryption MUST be generated as
as discussed in Section 4.7.1. discussed in Section 4.7.1.
* Additional authenticated data MUST be generated as discussed in * Additional authenticated data MUST be generated as discussed in
Section 4.7.2 with the value of AAD scope flags being taken from 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 the AAD scope flags security context parameter. If the AAD scope
flags parameter is not included in the security context flags parameter is not included in the security context
parameters, then these flags MAY be derived from local security parameters, then these flags MAY be derived from local security
policy in cases where the set of such flags is determinable in the policy in cases where the set of such flags is determinable in the
network. network.
* The authentication tag MUST be present either as a security result * The authentication tag MUST be present either as a security result
in the BCB representing the security operation or (with the cipher in the BCB representing the security operation or (with the
text) in the security target block-type-specific data field. ciphertext) in the security target block-type-specific data field.
Upon successful decryption the following actions MUST occur. Upon successful decryption, the following action MUST occur.
* The plain text produced by AES/GCM MUST replace the bytes used to * The plaintext produced by AES-GCM MUST replace the bytes used to
define the cipher text in the security target block's block-type- define the ciphertext in the security target block's block-type-
specific data field. Any changes to the security target block specific data field. Any changes to the security target block
length field MUST be corrected in cases where the plain text has a length field MUST be corrected in cases where the plaintext has a
different length than the replaced cipher text. different length than the replaced ciphertext.
If the security acceptor is not the bundle destination and if no If the security acceptor is not the bundle destination and if no
other integrity or confidentiality service is being applied to the other integrity or confidentiality service is being applied to the
target block, then a CRC MUST be included for the target block. The target block, then a CRC MUST be included for the target block. The
CRC type, as determined by policy, is set in the target block's CRC 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 type field and the corresponding CRC value is added as the CRC field
for that block. for that block.
If the cipher text fails to authenticate, if any needed parameters If the ciphertext fails to authenticate, if any needed parameters are
are missing, or if there are other problems in the decryption, then missing, or if there are other problems in the decryption, then the
the decryption MUST be treated as failed and processed in accordance decryption MUST be treated as failed and processed in accordance with
with local security policy. local security policy.
5. IANA Considerations 5. IANA Considerations
5.1. Security Context Identifiers 5.1. Security Context Identifiers
This specification allocates two security context identifiers from This specification allocates two security context identifiers from
the "BPSec Security Context Identifiers" registry defined in the "BPSec Security Context Identifiers" registry defined in
[RFC9172]. [RFC9172].
+=======+===============+===========+ +=======+===============+===========+
skipping to change at line 1231 skipping to change at line 1252
The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field
for which IANA has created and now maintains a new registry named for which IANA has created and now maintains a new registry named
"BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the "Bundle Protocol" "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the "Bundle Protocol"
registry page. Table 9 shows the initial values for this registry. registry page. Table 9 shows the initial values for this registry.
The registration policy for this registry is Specification Required The registration policy for this registry is Specification Required
[RFC8126]. [RFC8126].
The value range is unsigned 16-bit integer. The value range is unsigned 16-bit integer.
+==============================+=======================+===========+ +==============================+==================+===========+
| Bit Position (right to left) | Description | Reference | | Bit Position (right to left) | Description | Reference |
+==============================+=======================+===========+ +==============================+==================+===========+
| 0 | Include primary block | RFC 9173 | | 0 | Include primary | RFC 9173 |
+------------------------------+-----------------------+-----------+ | | block flag | |
| 1 | Include target header | RFC 9173 | +------------------------------+------------------+-----------+
| | flag | | | 1 | Include target | RFC 9173 |
+------------------------------+-----------------------+-----------+ | | header flag | |
| 2 | Include security | RFC 9173 | +------------------------------+------------------+-----------+
| | header flag | | | 2 | Include security | RFC 9173 |
+------------------------------+-----------------------+-----------+ | | header flag | |
| 3-7 | Reserved | RFC 9173 | +------------------------------+------------------+-----------+
+------------------------------+-----------------------+-----------+ | 3-7 | Reserved | RFC 9173 |
| 8-15 | Unassigned | | +------------------------------+------------------+-----------+
+------------------------------+-----------------------+-----------+ | 8-15 | Unassigned | |
+------------------------------+------------------+-----------+
Table 9: BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry Table 9: BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry
5.3. AAD Scope Flags 5.3. AAD Scope Flags
The BCB-AES-GCM security context has an AAD Scope Flags field for 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 which IANA has created and now maintains a new registry named "BPSec
BCB-AES-GCM AAD Scope Flags" on the "Bundle Protocol" registry page. BCB-AES-GCM AAD Scope Flags" on the "Bundle Protocol" registry page.
Table 10 shows the initial values for this registry. Table 10 shows the initial values for this registry.
The registration policy for this registry is Specification Required. The registration policy for this registry is Specification Required.
The value range is unsigned 16-bit integer. The value range is unsigned 16-bit integer.
+==============================+=======================+===========+ +==============================+==================+===========+
| Bit Position (right to left) | Description | Reference | | Bit Position (right to left) | Description | Reference |
+==============================+=======================+===========+ +==============================+==================+===========+
| 0 | Include primary block | RFC 9173 | | 0 | Include primary | RFC 9173 |
+------------------------------+-----------------------+-----------+ | | block flag | |
| 1 | Include target header | RFC 9173 | +------------------------------+------------------+-----------+
| | flag | | | 1 | Include target | RFC 9173 |
+------------------------------+-----------------------+-----------+ | | header flag | |
| 2 | Include security | RFC 9173 | +------------------------------+------------------+-----------+
| | header flag | | | 2 | Include security | RFC 9173 |
+------------------------------+-----------------------+-----------+ | | header flag | |
| 3-7 | Reserved | RFC 9173 | +------------------------------+------------------+-----------+
+------------------------------+-----------------------+-----------+ | 3-7 | Reserved | RFC 9173 |
| 8-15 | Unassigned | | +------------------------------+------------------+-----------+
+------------------------------+-----------------------+-----------+ | 8-15 | Unassigned | |
+------------------------------+------------------+-----------+
Table 10: BPSec BCB-AES-GCM AAD Scope Flags Registry Table 10: BPSec BCB-AES-GCM AAD Scope Flags Registry
5.4. Guidance for Designated Experts 5.4. Guidance for Designated Experts
New assignments within the "BPSec BIB-HMAC-SHA2 Integrity Scope New assignments within the "BPSec BIB-HMAC-SHA2 Integrity Scope
Flags" and "BPSec BCB-AES-GCM AAD Scope Flags" registries require Flags" and "BPSec BCB-AES-GCM AAD Scope Flags" registries require
review by a Designated Expert (DE). This section provides guidance review by a Designated Expert (DE). This section provides guidance
to the DE when performing their reviews. Specifically, a DE is to the DE when performing their reviews. Specifically, a DE is
expected to perform the following activities. expected to perform the following activities.
* Ascertain the existence of suitable documentation (a * Ascertain the existence of suitable documentation (a
specification) as described in [RFC8126] and verify that the specification) as described in [RFC8126] and verify that the
document is permanently and publicly available. document is permanently and publicly available.
* Ensure that any changes to the Integrity Scope Flags clearly state * Ensure that any changes to the "BPSec BIB-HMAC-SHA2 Integrity
how new assignments interact with existing flags and how the Scope Flags" registry clearly state how new assignments interact
inclusion of new assignments affects the construction of the IPPT with existing flags and how the inclusion of new assignments
value. affects the construction of the IPPT value.
* Ensure that any changes to the AAD Scope Flags clearly state how * Ensure that any changes to the "BPSec BCB-AES-GCM AAD Scope Flags"
new assignments interact with existing flags and how the inclusion registry clearly state how new assignments interact with existing
of new assignments affects the construction of the AAD input to flags and how the inclusion of new assignments affects the
the BCB-AES-GCM mechanism. construction of the AAD input to the BCB-AES-GCM mechanism.
* Ensure that any processing changes proposed with new assignments * Ensure that any processing changes proposed with new assignments
do not alter any required behavior in this specification. do not alter any required behavior in this specification.
6. Security Considerations 6. Security Considerations
Security considerations specific to a single security context are Security considerations specific to a single security context are
provided in the description of that context (see Sections 3 and 4). provided in the description of that context (see Sections 3 and 4).
This section discusses security considerations that should be This section discusses security considerations that should be
evaluated by implementers of any security context described in this evaluated by implementers of any security context described in this
document. Considerations can also be found in documents listed as document. Considerations can also be found in documents listed as
normative references and should also be reviewed by security context normative references and should also be reviewed by security context
implementors. implementors.
6.1. Key Management 6.1. Key Management
The delayed and disrupted nature of Delay-Tolerant Networks (DTNs) The delayed and disrupted nature of Delay-Tolerant Networking (DTN)
complicates the process of key management because there might not be complicates the process of key management because there might not be
reliable, timely, round-trip exchange between security sources, reliable, timely, round-trip exchange between security sources,
security verifiers, and security acceptors in the network. This is security verifiers, and security acceptors in the network. This is
true when there is a substantial signal propagation delay between true when there is a substantial signal propagation delay between
nodes, when nodes are in a highly challenged communications nodes, when nodes are in a highly challenged communications
environment, and when nodes do not support bidirectional environment, and when nodes do not support bidirectional
communication. communication.
In these environments, key establishment protocols that rely on In these environments, key establishment protocols that rely on
round-trip information exchange might not converge on a shared secret round-trip information exchange might not converge on a shared secret
in a timely manner (or at all). Also, key revocation or key in a timely manner (or at all). Also, key revocation or key
verification mechanisms that rely on access to a centralized verification mechanisms that rely on access to a centralized
authority (such as a certificate authority) might similarly fail in authority (such as a certificate authority) might similarly fail in
the stressing conditions of a DTN. the stressing conditions of DTN.
For these reasons, the default security contexts described in this For these reasons, the default security contexts described in this
document rely on symmetric-key cryptographic mechanisms because document rely on symmetric-key cryptographic mechanisms because
asymmetric-key infrastructure (such as a public key infrastructure) asymmetric-key infrastructure (such as a public key infrastructure)
might be impractical in this environment. might be impractical in this environment.
BPSec assumes that "key management is handled as a separate part of BPSec assumes that "key management is handled as a separate part of
network management" [RFC9172]. This assumption is also made by the network management" [RFC9172]. This assumption is also made by the
security contexts defined in this document, which do not define new security contexts defined in this document, which do not define new
protocols for key derivation, exchange of key-encrypting keys, protocols for key derivation, exchange of KEKs, revocation of
revocation of existing keys, or the security configuration or policy existing keys, or the security configuration or policy used to select
used to select certain keys for certain security operations. certain keys for certain security operations.
Nodes using these security contexts need to perform the following Nodes using these security contexts need to perform the following
kinds of activities, independent of the construction, transmission, kinds of activities, independent of the construction, transmission,
and processing of BPSec security blocks. and processing of BPSec security blocks.
* Establish shared key-encrypting-keys with other nodes in the * Establish shared KEKs with other nodes in the network using an
network using an out-of-band mechanism. This might include pre- out-of-band mechanism. This might include pre-sharing of KEKs or
sharing of key encryption keys or the use of traditional key the use of older key establishment mechanisms prior to the
establishment mechanisms prior to the exchange of BPSec security exchange of BPSec security blocks.
blocks.
* Determine when a key is considered exhausted and no longer to be * Determine when a key is considered exhausted and no longer to be
used in the generation, verification, or acceptance of a security used in the generation, verification, or acceptance of a security
block. block.
* Determine when a key is considered invalid and no longer to be * Determine when a key is considered invalid and no longer to be
used in the generation, verification, or acceptance of a security used in the generation, verification, or acceptance of a security
block. Such revocations can be based on a variety of mechanisms, block. Such revocations can be based on a variety of mechanisms,
including local security policy, time relative to the generation including local security policy, time relative to the generation
or use of the key, or other mechanisms specified through network or use of the key, or other mechanisms specified through network
skipping to change at line 1389 skipping to change at line 1411
* It is strongly RECOMMENDED that implementations protect keys both * It is strongly RECOMMENDED that implementations protect keys both
when they are stored and when they are transmitted. when they are stored and when they are transmitted.
* In the event that a key is compromised, any security operations * In the event that a key is compromised, any security operations
using a security context associated with that key SHOULD also be using a security context associated with that key SHOULD also be
considered compromised. This means that the BIB-HMAC-SHA2 considered compromised. This means that the BIB-HMAC-SHA2
security context SHOULD NOT be treated as providing integrity when security context SHOULD NOT be treated as providing integrity when
used with a compromised key, and BCB-AES-GCM SHOULD NOT be treated used with a compromised key, and BCB-AES-GCM SHOULD NOT be treated
as providing confidentiality when used with a compromised key. as providing confidentiality when used with a compromised key.
* The same key, whether a key-encrypting-key or a wrapped key, MUST * The same key, whether a KEK or a wrapped key, MUST NOT be used for
NOT be used for different algorithms as doing so might leak different algorithms as doing so might leak information about the
information about the key. key.
* A key-encrypting-key MUST NOT be used to encrypt keys for * A KEK MUST NOT be used to encrypt keys for different security
different security contexts. Any key-encrypting-key used by a contexts. Any KEK used by a security context defined in this
security context defined in this document MUST only be used to document MUST only be used to wrap keys associated with security
wrap keys associated with security operations using that security operations using that security context. This means that a
context. This means that a compliant security source would not compliant security source would not use the same KEK to wrap keys
use the same key-encrypting-key to wrap keys for both the BIB- for both the BIB-HMAC-SHA2 and BCB-AES-GCM security contexts.
HMAC-SHA2 and BCB-AES-GCM security contexts. Similarly, any Similarly, any compliant security verifier or security acceptor
compliant security verifier or security acceptor would not use the would not use the same KEK to unwrap keys for different security
same key-encrypting-key to unwrap keys for different security
contexts. contexts.
6.3. AES GCM 6.3. AES GCM
There are a significant number of considerations related to the use There are a significant number of considerations related to the use
of the GCM mode of AES to provide a confidentiality service. These of the GCM mode of AES to provide a confidentiality service. These
considerations are provided in Section 4.6 as part of the considerations are provided in Section 4.6 as part of the
documentation of the BCB-AES-GCM security context. documentation of the BCB-AES-GCM security context.
The length of the cipher text produced by the GCM mode of AES will be The length of the ciphertext produced by the GCM mode of AES will be
equal to the length of the plain text input to the cipher suite. The equal to the length of the plaintext input to the cipher suite. The
authentication tag also produced by this cipher suite is separate authentication tag also produced by this cipher suite is separate
from the cipher text. However, it should be noted that from the ciphertext. However, it should be noted that
implementations of the AES-GCM cipher suite might not separate the implementations of the AES-GCM cipher suite might not separate the
concept of cipher text and authentication tag in their Application concept of ciphertext and authentication tag in their Application
Programming Interface (API). Programming Interface (API).
Implementations of the BCB-AES-GCM security context can either keep Implementations of the BCB-AES-GCM security context can either keep
the length of the target block unchanged by holding the the length of the target block unchanged by holding the
authentication tag in a BCB security result or alter the length of authentication tag in a BCB security result or alter the length of
the target block by including the authentication tag with the cipher the target block by including the authentication tag with the
text replacing the block-type-specific-data field of the target ciphertext replacing the block-type-specific data field of the target
block. Implementations MAY use the authentication tag security block. Implementations MAY use the authentication tag security
result in cases where keeping target block length unchanged is an result in cases where keeping target block length unchanged is an
important processing concern. In all cases, the cipher text and important processing concern. In all cases, the ciphertext and
authentication tag MUST be processed in accordance with the API of authentication tag MUST be processed in accordance with the API of
the AES-GCM cipher suites at the security source and security the AES-GCM cipher suites at the security source and security
acceptor. acceptor.
6.4. AES Key Wrap 6.4. AES Key Wrap
The AES key wrap (AES-KW) algorithm used by the security contexts in The AES-KW algorithm used by the security contexts in this document
this document does not use a per-invocation initialization vector and does not use a per-invocation initialization vector and does not
does not require any key padding. Key padding is not needed because require any key padding. Key padding is not needed because wrapped
wrapped keys used by these security contexts will always be multiples keys used by these security contexts will always be multiples of 8
of 8 bytes. The length of the wrapped key can be determined by bytes. The length of the wrapped key can be determined by inspecting
inspecting the security context parameters. Therefore, a key can be the security context parameters. Therefore, a key can be unwrapped
unwrapped using only the information present in the security block using only the information present in the security block and the KEK
and the key encryption key provided by local security policy at the provided by local security policy at the security verifier or
security verifier or security acceptor. security acceptor.
6.5. Bundle Fragmentation 6.5. Bundle Fragmentation
Bundle fragmentation might prevent security services in a bundle from Bundle fragmentation might prevent security services in a bundle from
being verified after a bundle is fragmented and before the bundle is being verified after a bundle is fragmented and before the bundle is
re-assembled. Examples of potential issues include the following. re-assembled. Examples of potential issues include the following.
* If a security block and its security target do not exist in the * If a security block and its security target do not exist in the
same fragment, then the security block cannot be processed until same fragment, then the security block cannot be processed until
the bundle is re-assembled. If a fragment includes an encrypted the bundle is re-assembled. If a fragment includes an encrypted
skipping to change at line 1497 skipping to change at line 1518
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649, (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
DOI 10.17487/RFC5649, September 2009, September 2002, <https://www.rfc-editor.org/info/rfc3394>.
<https://www.rfc-editor.org/info/rfc5649>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
skipping to change at line 1526 skipping to change at line 1546
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>. <https://www.rfc-editor.org/info/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle [RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
November 2021, <https://www.rfc-editor.org/rfc/rfc9171>. December 2021, <https://www.rfc-editor.org/rfc/rfc9171>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol [RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security Specification", RFC 9172, DOI 10.17487/RFC9172, Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172,
November 2021, <https://www.rfc-editor.org/rfc/rfc9172>. December 2021, <https://www.rfc-editor.org/rfc/rfc9172>.
[SHS] National Institute of Standards and Technology, "Secure [SHS] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015, DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://csrc.nist.gov/publications/detail/fips/180/4/ <https://csrc.nist.gov/publications/detail/fips/180/4/
final>. final>.
Appendix A. Examples Appendix A. Examples
This appendix is informative. This appendix is informative.
This appendix presents a series of examples of constructing BPSec This appendix presents a series of examples of constructing BPSec
security blocks (using the security contexts defined in this security blocks (using the security contexts defined in this
document) and adding those blocks to a sample bundle. document) and adding those blocks to a sample bundle.
The examples presented in this appendix represent valid constructions The examples presented in this appendix represent valid constructions
of bundles, security blocks, and the encoding of security context of bundles, security blocks, and the encoding of security context
parameters and results. For this reason, they can inform unit test parameters and results. For this reason, they can inform unit test
suites for individual implementations as well as interoperability suites for individual implementations as well as interoperability
test suites amongst implementations. However, these examples do not test suites amongst implementations. However, these examples do not
cover every permutation of security parameters, security results, or cover every permutation of security context parameters, security
use of security blocks in a bundle. results, or use of security blocks in a bundle.
NOTES: NOTES:
* The bundle diagrams in this appendix are patterned after the * The bundle diagrams in this appendix are patterned after the
bundle diagrams used in Section 3.11 ("BSP Block Examples") of bundle diagrams used in Section 3.11 ("BSP Block Examples") of
[RFC9172]. [RFC9172].
* Figures in this appendix identified as "(CBOR Diagnostic * Figures in this appendix identified as "(CBOR Diagnostic
Notation)" are represented using the CBOR diagnostic notation Notation)" are represented using the CBOR diagnostic notation
defined in [RFC8949]. This notation is used to express CBOR data defined in [RFC8949]. This notation is used to express CBOR data
structures in a manner that enables visual inspection. The structures in a manner that enables visual inspection. The
bundles, security blocks, and security context contents in these bundles, security blocks, and security context contents in these
figures are represented using CBOR structures. In cases where BP figures are represented using CBOR structures. In cases where BP
blocks (to include BPSec security blocks) are comprised of a blocks (to include BPSec security blocks) are comprised of a
sequence of CBOR objects, these objects are represented as a CBOR sequence of CBOR objects, these objects are represented as a CBOR
sequence as defined in [RFC8742]. sequence as defined in [RFC8742].
* Examples in this appendix use the "ipn" URI scheme for Endpoint ID * Examples in this appendix use the "ipn" URI scheme for endpoint ID
naming, as defined in [RFC9171]. naming, as defined in [RFC9171].
* The bundle source is presumed to be the security source for all * The bundle source is presumed to be the security source for all
security blocks in this appendix, unless otherwise noted. security blocks in this appendix, unless otherwise noted.
A.1. Example 1: Simple Integrity A.1. Example 1 - Simple Integrity
This example shows the addition of a BIB to a sample bundle to This example shows the addition of a BIB to a sample bundle to
provide integrity for the payload block. provide integrity for the payload block.
A.1.1. Original Bundle A.1.1. Original Bundle
The following diagram shows the original bundle before the BIB has The following diagram shows the original bundle before the BIB has
been added. been added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block | 1 | 1 | | Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 1: Example 1: Original Bundle Figure 1: Example 1 - Original Bundle
A.1.1.1. Primary Block A.1.1.1. Primary Block
The BPv7 bundle has no special processing flags, and no CRC is The Bundle Protocol version 7 (BPv7) bundle has no special block and
provided because the primary block is expected to be protected by an bundle processing control flags, and no CRC is provided because the
integrity service BIB using the BIB-HMAC-SHA2 security context. 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 The bundle is sourced at the source node ipn:2.1 and destined for the
destination node ipn:1.2. The bundle creation time uses a DTN destination node ipn:1.2. The bundle creation time is set to 0,
creation time of 0 indicating lack of an accurate clock and a indicating lack of an accurate clock, with a sequence number of 40.
sequence number of 40. The lifetime of the bundle is given as The lifetime of the bundle is given as 1,000,000 milliseconds since
1,000,000 milliseconds since the bundle creation time. the bundle creation time.
The primary block is provided as follows. The primary block is provided as follows.
[ [
7, / BP version / 7, / BP version /
0, / flags / 0, / flags /
0, / CRC type / 0, / CRC type /
[2, [1,2]], / destination (ipn:1.2) / [2, [1,2]], / destination (ipn:1.2) /
[2, [2,1]], / source (ipn:2.1) / [2, [2,1]], / source (ipn:2.1) /
[2, [2,1]], / report-to (ipn:2.1) / [2, [2,1]], / report-to (ipn:2.1) /
[0, 40], / timestamp / [0, 40], / timestamp /
1000000 / lifetime / 1000000 / lifetime /
] ]
Figure 2: Primary Block (CBOR Diagnostic Notation) Figure 2: Primary Block (CBOR Diagnostic Notation)
The CBOR encoding of the primary block is The CBOR encoding of the primary block is:
0x88070000820282010282028202018202820201820018281a000f4240.
0x88070000820282010282028202018202820201820018281a000f4240
A.1.1.2. Payload Block A.1.1.2. Payload Block
Other than its use as a source of plain text for security blocks, the Other than its use as a source of plaintext for security blocks, the
payload has no required distinguishing characteristic for the purpose payload has no required distinguishing characteristic for the purpose
of this example. The sample payload is a 32-byte string whose value of this example. The sample payload is a 35-byte string.
is "Ready Generate a 32-byte payload".
The payload is represented in the payload block as a byte string of 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 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 wrapped within a CBOR binary string. The hex value of the payload
"Ready Generate a 32-byte payload" is is:
0x52656164792047656e657261746520612033322062797465207061796c6f6164.
0x526561647920746f2067656e657261746520612033322d62797465207061796c6f
6164
The payload block is provided as follows. The payload block is provided as follows.
[ [
1, / type code: Payload block / 1, / type code: Payload block /
1, / block number / 1, / block number /
0, / block processing flags / 0, / block processing control flags /
0, / CRC type / 0, / CRC type /
h'52656164792047656e65726174652061 / type-specific-data: payload / h'526561647920746f206765 / type-specific-data: payload /
2033322062797465207061796c6f6164' 6e657261746520612033322d
62797465207061796c6f6164'
] ]
Figure 3: Payload Block (CBOR Diagnostic Notation) Figure 3: Payload Block (CBOR Diagnostic Notation)
The CBOR encoding of the payload block is 0x8501010000582052656164792 The CBOR encoding of the payload block is:
047656e657261746520612033322062797465207061796c6f6164.
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
A.1.1.3. Bundle CBOR Representation A.1.1.3. Bundle CBOR Representation
A BPv7 bundle is represented as an indefinite-length array consisting A BPv7 bundle is represented as an indefinite-length array consisting
of the blocks comprising the bundle, with a terminator character at of the blocks comprising the bundle, with a terminator character at
the end. the end.
The CBOR encoding of the original bundle is 0x9f880700008202820102820 The CBOR encoding of the original bundle is:
28202018202820201820018281a000f42408501010000582052656164792047656e65
7261746520612033322062797465207061796c6f6164ff. 0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
A.1.2. Security Operation Overview A.1.2. Security Operation Overview
This example adds a BIB to the bundle using the BIB-HMAC-SHA2 This example adds a BIB to the bundle using the BIB-HMAC-SHA2
security context to provide an integrity mechanism over the payload security context to provide an integrity mechanism over the payload
block. block.
The following diagram shows the resulting bundle after the BIB is The following diagram shows the resulting bundle after the BIB is
added. added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Integrity Block | 11 | 2 | | Block Integrity Block | 11 | 2 |
| OP(bib-integrity, target=1) | | | | OP(bib-integrity, target=1) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block | 1 | 1 | | Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 4: Example 1: Resulting Bundle Figure 4: Example 1 - Resulting Bundle
A.1.3. Bundle Integrity Block A.1.3. Block Integrity Block
In this example, a BIB is used to carry an integrity signature over In this example, a BIB is used to carry an integrity signature over
the payload block. the payload block.
A.1.3.1. Configuration, Parameters, and Results A.1.3.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters For this example, the following configuration and security context
are used to generate the security results indicated. parameters are used to generate the security results indicated.
This BIB has a single target and includes a single security result: This BIB has a single target and includes a single security result:
the calculated signature over the payload block. the calculated signature over the payload block.
Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
SHA Variant : HMAC 512/512 SHA Variant : HMAC 512/512
Scope Flags : 0x00 Scope Flags : 0x00
Payload Data: h'52656164792047656e65726174652061 Payload Data: h'526561647920746f2067656e65726174
2033322062797465207061796c6f6164' 6520612033322d62797465207061796c
Signature : h'0654d65992803252210e377d66d0a8dc 6f6164'
18a1e8a392269125ae9ac198a9a598be IPPT : h'005823526561647920746f2067656e65
4b83d5daa8be2f2d16769ec1c30cfc34 7261746520612033322d627974652070
8e2205fba4b3be2b219074fdd5ea8ef0' 61796c6f6164'
Signature : h'3bdc69b3a34a2b5d3a8554368bd1e808
f606219d2a10a846eae3886ae4ecc83c
4ee550fdfb1cc636b904e2f1a73e303d
cd4b6ccece003e95e8164dcc89a156e1'
Figure 5: Example 1: Configuration, Parameters, and Results Figure 5: Example 1 - Configuration, Parameters, and Results
A.1.3.2. Abstract Security Block A.1.3.2. Abstract Security Block
The abstract security block structure of the BIB's block-type- The abstract security block structure of the BIB's block-type-
specific-data field for this application is as follows. specific data field for this application is as follows.
[1], / Security Target - Payload block / [1], / Security Target - Payload block /
1, / Security Context ID - BIB-HMAC-SHA2 / 1, / Security Context ID - BIB-HMAC-SHA2 /
1, / Security Context Flags - Parameters Present / 1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 / [2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 2 Parameters / [ / Security Parameters - 2 Parameters /
[1, 7], / SHA Variant - HMAC 512/512 / [1, 7], / SHA Variant - HMAC 512/512 /
[3, 0x00] / Scope Flags - No Additional Scope / [3, 0x00] / Scope Flags - No Additional Scope /
], ],
[ / Security Results: 1 Result / [ / Security Results: 1 Result /
[1, h'0654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598b [ / Target 1 Results /
e4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0'] [1, h'3bdc69b3a34a2b5d3a8554368bd1e808 / MAC /
f606219d2a10a846eae3886ae4ecc83c
4ee550fdfb1cc636b904e2f1a73e303d
cd4b6ccece003e95e8164dcc89a156e1']
]
] ]
Figure 6: Example 1: BIB Abstract Security Block (CBOR Diagnostic Figure 6: Example 1 - BIB Abstract Security Block (CBOR
Notation) Diagnostic Notation)
The CBOR encoding of the BIB block-type-specific-data field (the The CBOR encoding of the BIB block-type-specific data field (the
abstract security block) is 0x810101018202820201828201078203008182015 abstract security block) is:
8400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b
83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0. 0x810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a8554
368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2f1a7
3e303dcd4b6ccece003e95e8164dcc89a156e1
A.1.3.3. Representations A.1.3.3. Representations
The BIB wrapping this abstract security block is as follows. The complete BIB is as follows.
[ [
11, / type code / 11, / type code /
2, / block number / 2, / block number /
0, / flags / 0, / flags /
0, / CRC type / 0, / CRC type /
h'8101010182028202018282010782030081820158400654d65992803252210e377d66 h'810101018202820201828201078203008181820158403bdc69b3a34a
d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc34 2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550
8e2205fba4b3be2b219074fdd5ea8ef0', fdfb1cc636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1'
] ]
Figure 7: Example 1: BIB (CBOR Diagnostic Notation) Figure 7: Example 1 - BIB (CBOR Diagnostic Notation)
The CBOR encoding of the BIB block is 0x850b0200005855810101018202820 The CBOR encoding of the BIB block is:
2018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392
269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2 0x850b0200005856810101018202820201828201078203008181820158403bdc69b3
b219074fdd5ea8ef0. a34a2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1c
c636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1
A.1.4. Final Bundle A.1.4. Final Bundle
The CBOR encoding of the full output bundle, with the BIB: 0x9f880700 The CBOR encoding of the full output bundle, with the BIB:
00820282010282028202018202820201820018281a000f4240850b020000585581010
1018202820201828201078203008182015840 0654d65992803252210e377d66d0a8d
c18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e22
05fba4b3be2b219074fdd5ea8ef08501010000582052656164792047656e657261746
520612033322062797465207061796c6f6164ff.
A.2. Example 2: Simple Confidentiality with Key Wrap 0x9f88070000820282010282028202018202820201820018281a000f4240850b0200
005856810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a
8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2
f1a73e303dcd4b6ccece003e95e8164dcc89a156e185010100005823526561647920
746f2067656e657261746520612033322d62797465207061796c6f6164ff
A.2. Example 2 - Simple Confidentiality with Key Wrap
This example shows the addition of a BCB to a sample bundle to This example shows the addition of a BCB to a sample bundle to
provide confidentiality for the payload block. AES key wrap is used provide confidentiality for the payload block. AES key wrap is used
to transmit the symmetric key used to generate the security results to transmit the symmetric key used to generate the security results
for this service. for this service.
A.2.1. Original Bundle A.2.1. Original Bundle
The following diagram shows the original bundle before the BCB has The following diagram shows the original bundle before the BCB has
been added. been added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block | 1 | 1 | | Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 8: Example 2: Original Bundle Figure 8: Example 2 - Original Bundle
A.2.1.1. Primary Block A.2.1.1. Primary Block
The primary block used in this example is identical to the primary The primary block used in this example is identical to the primary
block presented for Example 1 in Appendix A.1.1.1. block presented for Example 1 in Appendix A.1.1.1.
In summary, the CBOR encoding of the primary block is In summary, the CBOR encoding of the primary block is:
0x88070000820282010282028202018202820201820018281a000f4240.
0x88070000820282010282028202018202820201820018281a000f4240
A.2.1.2. Payload Block A.2.1.2. Payload Block
The payload block used in this example is identical to the payload The payload block used in this example is identical to the payload
block presented for Example 1 in Appendix A.1.1.2. block presented for Example 1 in Appendix A.1.1.2.
In summary, the CBOR encoding of the payload block is 0x8501010000582 In summary, the CBOR encoding of the payload block is:
052656164792047656e657261746520612033322062797465207061796c6f6164.
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
A.2.1.3. Bundle CBOR Representation A.2.1.3. Bundle CBOR Representation
A BPv7 bundle is represented as an indefinite-length array consisting A BPv7 bundle is represented as an indefinite-length array consisting
of the blocks comprising the bundle, with a terminator character at of the blocks comprising the bundle, with a terminator character at
the end. the end.
The CBOR encoding of the original bundle is 0x9f880700008202820102820 The CBOR encoding of the original bundle is:
28202018202820201820018281a000f42408501010000582052656164792047656e65
7261746520612033322062797465207061796c6f6164ff. 0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
A.2.2. Security Operation Overview A.2.2. Security Operation Overview
This example adds a BCB using the BCB-AES-GCM security context using This example adds a BCB using the BCB-AES-GCM security context using
AES key wrap to provide a confidentiality mechanism over the payload AES key wrap to provide a confidentiality mechanism over the payload
block and transmit the symmetric key. block and transmit the symmetric key.
The following diagram shows the resulting bundle after the BCB is The following diagram shows the resulting bundle after the BCB is
added. added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Confidentiality Block | 12 | 2 | | Block Confidentiality Block | 12 | 2 |
| OP(bcb-confidentiality, target=1) | | | | OP(bcb-confidentiality, target=1) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 1 | 1 | | Payload Block (Encrypted) | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 9: Example 2: Resulting Bundle Figure 9: Example 2 - Resulting Bundle
A.2.3. Bundle Confidentiality Block A.2.3. Block Confidentiality Block
In this example, a BCB is used to encrypt the payload block and uses In this example, a BCB is used to encrypt the payload block, and AES
AES key wrap to transmit the symmetric key. key wrap is used to encode the symmetric key prior to its inclusion
in the BCB.
A.2.3.1. Configuration, Parameters, and Results A.2.3.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters For this example, the following configuration and security context
are used to generate the security results indicated. parameters are used to generate the security results indicated.
This BCB has a single target -- the payload block. Three security This BCB has a single target -- the payload block. Three security
results are generated: cipher text that replaces the plain text results are generated: ciphertext that replaces the plaintext block-
block-type-specific data to encrypt the payload block, an type-specific data to encrypt the payload block, an authentication
authentication tag, and the AES wrapped key. tag, and the AES wrapped key.
Content Encryption Content Encryption
Key: h'71776572747975696f70617364666768' Key: h'71776572747975696f70617364666768'
Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70' Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70'
IV: h'5477656c7665313231323132' IV: h'5477656c7665313231323132'
AES Variant: A128GCM AES Variant: A128GCM
AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892 AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892
96fabf34d7fae700' 96fabf34d7fae700'
Scope Flags: 0x00 Scope Flags: 0x00
Payload Data: h'52656164792047656e65726174652061 Payload Data: h'526561647920746f2067656e65726174
2033322062797465207061796c6f6164' 6520612033322d62797465207061796c
Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' 6f6164'
Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 AAD: h'00'
a563e32648b700c2784e26a990d91f9d' Authentication Tag: h'efa4b5ac0108e3816c5606479801bc04'
Payload Ciphertext: h'3a09c1e63fe23a7f66a59c7303837241
e070b02619fc59c5214a22f08cd70795
e73e9a'
Figure 10: Example 2: Configuration, Parameters, and Results Figure 10: Example 2 - Configuration, Parameters, and Results
A.2.3.2. Abstract Security Block A.2.3.2. Abstract Security Block
The abstract security block structure of the BCB's block-type- The abstract security block structure of the BCB's block-type-
specific-data field for this application is as follows. specific data field for this application is as follows.
[1], / Security Target - Payload block / [1], / Security Target - Payload block /
2, / Security Context ID - BCB-AES-GCM / 2, / Security Context ID - BCB-AES-GCM /
1, / Security Context Flags - Parameters Present / 1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 / [2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 4 Parameters / [ / Security Parameters - 4 Parameters /
[1, h'5477656c7665313231323132'], / Initialization Vector / [1, h'5477656c7665313231323132'], / Initialization Vector /
[2, 1], / AES Variant - A128GCM / [2, 1], / AES Variant - A128GCM /
[3, h'69c411276fecddc4780df42c8a / AES wrapped key / [3, h'69c411276fecddc4780df42c8a / AES wrapped key /
2af89296fabf34d7fae700'], 2af89296fabf34d7fae700'],
[4, 0x00] / Scope Flags - No extra scope/ [4, 0x00] / Scope Flags - No extra scope/
], ],
[ / Security Results: 1 Result / [ / Security Results: 1 Result /
[1, h'da08f4d8936024ad7c6b3b800e73dd97'] / Payload Auth. Tag / [ / Target 1 Results /
[1, h'efa4b5ac0108e3816c5606479801bc04'] / Payload Auth. Tag /
]
] ]
Figure 11: Example 2: BCB Abstract Security Block (CBOR Figure 11: Example 2 - BCB Abstract Security Block (CBOR
Diagnostic Notation) Diagnostic Notation)
The CBOR encoding of the BCB block-type-specific-data field (the The CBOR encoding of the BCB block-type-specific data field (the
abstract security block) is 0x8101020182028202018482014c5477656c76653 abstract security block) is:
132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fa
e70082040081820150da08f4d8936024ad7c6b3b800e73dd97. 0x8101020182028202018482014c5477656c76653132313231328202018203581869
c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150efa4b5
ac0108e3816c5606479801bc04
A.2.3.3. Representations A.2.3.3. Representations
The BCB wrapping this abstract security block is as follows. The complete BCB is as follows.
[ [
12, / type code / 12, / type code /
2, / block number / 2, / block number /
1, / flags - block must be replicated in every fragment / 1, / flags - block must be replicated in every fragment /
0, / CRC type / 0, / CRC type /
h'8101020182028202018482014c5477656c766531323132313282020182035818 h'8101020182028202018482014c5477656c766531323132313282020182035818
69c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da 69c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150
08f4d8936024ad7c6b3b800e73dd97' efa4b5ac0108e3816c5606479801bc04'
] ]
Figure 12: Example 2: BCB (CBOR Diagnostic Notation) Figure 12: Example 2 - BCB (CBOR Diagnostic Notation)
The CBOR encoding of the BCB block is 0x850c020100584f810102018202820 The CBOR encoding of the BCB block is:
2018482014c5477656c76653132313231328202018203581869c411276fecddc4780d
f42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e7 0x850c02010058508101020182028202018482014c5477656c766531323132313282
3dd97. 02018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081
81820150efa4b5ac0108e3816c5606479801bc04
A.2.4. Final Bundle A.2.4. Final Bundle
The CBOR encoding of the full output bundle, with the BCB: 0x9f880700 The CBOR encoding of the full output bundle, with the BCB:
00820282010282028202018202820201820018281a000f4240850c020100584f81010
20182028202018482014c5477656c76653132313231328202018203581869c411276f
ecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7
c6b3b800e73dd97850101000058203a09c1e63fe2097528a78b7c12943354a563e326
48b700c2784e26a990d91f9dff.
A.3. Example 3: Security Blocks from Multiple Sources 0x9f88070000820282010282028202018202820201820018281a000f4240850c0201
0058508101020182028202018482014c5477656c7665313231323132820201820358
1869c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150ef
a4b5ac0108e3816c5606479801bc04850101000058233a09c1e63fe23a7f66a59c73
03837241e070b02619fc59c5214a22f08cd70795e73e9aff
A.3. Example 3 - Security Blocks from Multiple Sources
This example shows the addition of a BIB and BCB to a sample bundle. 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 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 is added by the source endpoint, and the BIB is added by a forwarding
node. node.
The resulting bundle contains a BCB to encrypt the Payload Block and The resulting bundle contains a BCB to encrypt the Payload Block and
a BIB to provide integrity to the Primary and Bundle Age Block. a BIB to provide integrity to the primary block and Bundle Age Block.
A.3.1. Original Bundle A.3.1. Original Bundle
The following diagram shows the original bundle before the security The following diagram shows the original bundle before the security
blocks have been added. blocks have been added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Extension Block: Bundle Age Block | 7 | 2 | | Extension Block: Bundle Age Block | 7 | 2 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block | 1 | 1 | | Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 13: Example 3: Original Bundle Figure 13: Example 3 - Original Bundle
A.3.1.1. Primary Block A.3.1.1. Primary Block
The primary block used in this example is identical to the primary The primary block used in this example is identical to the primary
block presented for Example 1 in Appendix A.1.1.1. block presented for Example 1 in Appendix A.1.1.1.
In summary, the CBOR encoding of the primary block is In summary, the CBOR encoding of the primary block is:
0x88070000820282010282028202018202820201820018281a000f4240.
0x88070000820282010282028202018202820201820018281a000f4240
A.3.1.2. Bundle Age Block A.3.1.2. Bundle Age Block
A bundle age block is added to the bundle to help other nodes in the A Bundle Age Block is added to the bundle to help other nodes in the
network determine the age of the bundle. The use of this block is as network determine the age of the bundle. The use of this block is
recommended because the bundle source does not have an accurate clock recommended because the bundle source does not have an accurate clock
(as indicated by the DTN time of 0). (as indicated by the DTN time of 0).
Because this block is specified at the time the bundle is being Because this block is specified at the time the bundle is being
forwarded, the bundle age represents the time that has elapsed from 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 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. forwarding. In this case, the value is given as 300 milliseconds.
The bundle age extension block is provided as follows. The Bundle Age extension block is provided as follows.
[ [
7, / type code: Bundle Age block / 7, / type code: Bundle Age Block /
2, / block number / 2, / block number /
0, / block processing flags / 0, / block processing control flags /
0, / CRC type / 0, / CRC type /
<<300>> / type-specific-data: age / <<300>> / type-specific-data: age /
] ]
Figure 14: Bundle Age Block (CBOR Diagnostic Notation) Figure 14: Bundle Age Block (CBOR Diagnostic Notation)
The CBOR encoding of the bundle age block is 0x85070200004319012c. The CBOR encoding of the Bundle Age Block is:
0x85070200004319012c
A.3.1.3. Payload Block A.3.1.3. Payload Block
The payload block used in this example is identical to the payload The payload block used in this example is identical to the payload
block presented for Example 1 in Appendix A.1.1.2. block presented for Example 1 in Appendix A.1.1.2.
In summary, the CBOR encoding of the payload block is 0x8501010000582 In summary, the CBOR encoding of the payload block is:
052656164792047656e657261746520612033322062797465207061796c6f6164.
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
A.3.1.4. Bundle CBOR Representation A.3.1.4. Bundle CBOR Representation
A BPv7 bundle is represented as an indefinite-length array consisting A BPv7 bundle is represented as an indefinite-length array consisting
of the blocks comprising the bundle, with a terminator character at of the blocks comprising the bundle, with a terminator character at
the end. the end.
The CBOR encoding of the original bundle is 0x9f880700008202820102820 The CBOR encoding of the original bundle is:
28202018202820201820018281a000f424085070200004319012c8501010000582052
656164792047656e657261746520612033322062797465207061796c6f6164ff. 0x9f88070000820282010282028202018202820201820018281a000f424085070200
004319012c85010100005823526561647920746f2067656e65726174652061203332
2d62797465207061796c6f6164ff
A.3.2. Security Operation Overview A.3.2. Security Operation Overview
This example provides: This example provides:
* a BIB with the BIB-HMAC-SHA2 security context to provide an * a BIB with the BIB-HMAC-SHA2 security context to provide an
integrity mechanism over the primary block and bundle age block. integrity mechanism over the primary block and Bundle Age Block.
* a BCB with the BCB-AES-GCM security context to provide a * a BCB with the BCB-AES-GCM security context to provide a
confidentiality mechanism over the payload block. confidentiality mechanism over the payload block.
The following diagram shows the resulting bundle after the security The following diagram shows the resulting bundle after the security
blocks are added. blocks are added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Integrity Block | 11 | 3 | | Block Integrity Block | 11 | 3 |
| OP(bib-integrity, targets=0, 2) | | | | OP(bib-integrity, targets=0, 2) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Confidentiality Block | 12 | 4 | | Block Confidentiality Block | 12 | 4 |
| OP(bcb-confidentiality, target=1) | | | | OP(bcb-confidentiality, target=1) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Extension Block: Bundle Age Block | 7 | 2 | | Extension Block: Bundle Age Block | 7 | 2 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 1 | 1 | | Payload Block (Encrypted) | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 15: Example 3: Resulting Bundle Figure 15: Example 3 - Resulting Bundle
A.3.3. Bundle Integrity Block A.3.3. Block Integrity Block
In this example, a BIB is used to carry an integrity signature over In this example, a BIB is used to carry an integrity signature over
the bundle age block and an additional signature over the payload the Bundle Age Block and an additional signature over the payload
block. The BIB is added by a waypoint node -- ipn:3.0. block. The BIB is added by a waypoint node -- ipn:3.0.
A.3.3.1. Configuration, Parameters, and Results A.3.3.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters For this example, the following configuration and security context
are used to generate the security results indicated. parameters are used to generate the security results indicated.
This BIB has two security targets and includes two security results, This BIB has two security targets and includes two security results,
holding the calculated signatures over the bundle age block and holding the calculated signatures over the Bundle Age Block and
primary block. primary block.
Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
SHA Variant: HMAC 256/256 SHA Variant: HMAC 256/256
Scope Flags: 0x00 Scope Flags: 0x00
Primary Block Data: h'88070000820282010282028202018202 Primary Block Data: h'88070000820282010282028202018202
820201820018281a000f4240' 820201820018281a000f4240'
Bundle Age Block Bundle Age Block
Data: h'85070200004319012c' Data: h'4319012c'
Primary Block IPPT: h'00581c88070000820282010282028202
018202820201820018281a000f4240'
Bundle Age Block
IPPT: h'004319012c'
Primary Block Primary Block
Signature: h'8e059b8e71f7218264185a666bf3e453 Signature: h'cac6ce8e4c5dae57988b757e49a6dd14
076f2b883f4dce9b3cdb6464ed0dcf0f' 31dc04763541b2845098265bc817241b'
Bundle Age Block Bundle Age Block
Signature: h'72dee8eba049a22978e84a95d0496466 Signature: h'3ed614c0d97f49b3633627779aa18a33
8eb131b1ca4800c114206d70d9065c80' 8d212bf3c92b97759d9739cd50725596'
Figure 16: Example 3: Configuration, Parameters, and Results for Figure 16: Example 3 - Configuration, Parameters, and Results for
the BIB the BIB
A.3.3.2. Abstract Security Block A.3.3.2. Abstract Security Block
The abstract security block structure of the BIB's block-type- The abstract security block structure of the BIB's block-type-
specific-data field for this application is as follows. specific data field for this application is as follows.
[0, 2], / Security Targets / [0, 2], / Security Targets /
1, / Security Context ID - BIB-HMAC-SHA2 / 1, / Security Context ID - BIB-HMAC-SHA2 /
1, / Security Context Flags - Parameters Present / 1, / Security Context Flags - Parameters Present /
[2,[3, 0]], / Security Source - ipn:3.0 / [2,[3, 0]], / Security Source - ipn:3.0 /
[ / Security Parameters - 2 Parameters / [ / Security Parameters - 2 Parameters /
[1, 5], / SHA Variant - HMAC 256/256 / [1, 5], / SHA Variant - HMAC 256 /
[3, 0x00] / Scope Flags - No Additional Scope / [3, 0] / Scope Flags - No Additional Scope /
], ],
[ / Security Results: 2 Results / [ / Security Results: 2 Results /
[1, h'8e059b8e71f7218264185a666bf3e453 [ / Primary Block Results /
076f2b883f4dce9b3cdb6464ed0dcf0f'], / Primary Block / [1, h'cac6ce8e4c5dae57988b757e49a6dd14
[1, h'72dee8eba049a22978e84a95d0496466 31dc04763541b2845098265bc817241b'] / MAC /
8eb131b1ca4800c114206d70d9065c80'] / Bundle Age Block / ],
[ / Bundle Age Block Results /
[1, h'3ed614c0d97f49b3633627779aa18a33
8d212bf3c92b97759d9739cd50725596'] / MAC /
]
] ]
Figure 17: Example 3: BIB Abstract Security Block (CBOR Figure 17: Example 3 - BIB Abstract Security Block (CBOR
Diagnostic Notation) Diagnostic Notation)
The CBOR encoding of the BIB block-type-specific-data field (the The CBOR encoding of the BIB block-type-specific data field (the
abstract security block) is 0x820002010182028203008282010582030082820 abstract security block) is:
158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f
8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065 0x8200020101820282030082820105820300828182015820cac6ce8e4c5dae57988b
c80. 757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d97f49
b3633627779aa18a338d212bf3c92b97759d9739cd50725596
A.3.3.3. Representations A.3.3.3. Representations
The BIB wrapping this abstract security block is as follows. The complete BIB is as follows.
[ [
11, / type code / 11, / type code /
3, / block number / 3, / block number /
0, / flags / 0, / flags /
0, / CRC type / 0, / CRC type /
h'820002010182028203008282010582030082820158208e059b8e71f721826418 h'8200020101820282030082820105820300828182015820cac6ce8e4c5dae5798
5a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049 8b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9
a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80', 7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596'
] ]
Figure 18: Example 3: BIB (CBOR Diagnostic Notation) Figure 18: Example 3 - BIB (CBOR Diagnostic Notation)
The CBOR encoding of the BIB block is 0x850b030000585a820002010182028 The CBOR encoding of the BIB block is:
203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b88
3f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb13
1b1ca4800c114206d70d9065c80.
A.3.4. Bundle Confidentiality Block 0x850b030000585c8200020101820282030082820105820300828182015820cac6ce
8e4c5dae57988b757e49a6dd1431dc04763541b2845098265bc817241b8182015820
3ed614c0d97f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596
A.3.4. Block Confidentiality Block
In this example, a BCB is used encrypt the payload block. The BCB is In this example, a BCB is used encrypt the payload block. The BCB is
added by the bundle source node, ipn:2.1. added by the bundle source node, ipn:2.1.
A.3.4.1. Configuration, Parameters, and Results A.3.4.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters For this example, the following configuration and security context
are used to generate the security results indicated. parameters are used to generate the security results indicated.
This BCB has a single target, the payload block. Two security This BCB has a single target, the payload block. Two security
results are generated: cipher text that replaces the plain text results are generated: ciphertext that replaces the plaintext block-
block-type-specific data to encrypt the payload block and an type-specific data to encrypt the payload block and an authentication
authentication tag. tag.
Content Encryption Content Encryption
Key: h'71776572747975696f70617364666768' Key: h'71776572747975696f70617364666768'
IV: h'5477656c7665313231323132' IV: h'5477656c7665313231323132'
AES Variant: A128GCM AES Variant: A128GCM
Scope Flags: 0x00 Scope Flags: 0x00
Payload Data: h'52656164792047656e65726174652061 Payload Data: h'526561647920746f2067656e65726174
2033322062797465207061796c6f6164' 6520612033322d62797465207061796c
Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97' 6f6164'
Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 AAD: h'00'
a563e32648b700c2784e26a990d91f9d' Authentication Tag: h'efa4b5ac0108e3816c5606479801bc04'
Payload Ciphertext: h'3a09c1e63fe23a7f66a59c7303837241
e070b02619fc59c5214a22f08cd70795
e73e9a'
Figure 19: Example 3: Configuration, Parameters, and Results for Figure 19: Example 3 - Configuration, Parameters, and Results for
the BCB the BCB
A.3.4.2. Abstract Security Block A.3.4.2. Abstract Security Block
The abstract security block structure of the BCB's block-type- The abstract security block structure of the BCB's block-type-
specific-data field for this application is as follows. specific data field for this application is as follows.
[1], / Security Target - Payload block / [1], / Security Target - Payload block /
2, / Security Context ID - BCB-AES-GCM / 2, / Security Context ID - BCB-AES-GCM /
1, / Security Context Flags - Parameters Present / 1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 / [2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 3 Parameters / [ / Security Parameters - 3 Parameters /
[1, h'5477656c7665313231323132'], / Initialization Vector / [1, h'5477656c7665313231323132'], / Initialization Vector /
[2, 1], / AES Variant - AES 128 / [2, 1], / AES Variant - AES 128 /
[4, 0x00] / Scope Flags - No Additional Scope / [4, 0] / Scope Flags - No Additional Scope /
], ],
[ / Security Results: 1 Result / [ / Security Results: 1 Result /
[1, h'da08f4d8936024ad7c6b3b800e73dd97'] / Payload Auth. Tag / [
[1, h'efa4b5ac0108e3816c5606479801bc04'] / Payload Auth. Tag /
]
] ]
Figure 20: Example 3: BCB Abstract Security Block (CBOR Figure 20: Example 3 - BCB Abstract Security Block (CBOR
Diagnostic Notation) Diagnostic Notation)
The CBOR encoding of the BCB block-type-specific-data field (the The CBOR encoding of the BCB block-type-specific data field (the
abstract security block) is 0x8101020182028202018382014c5477656c76653 abstract security block) is:
1323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd97.
0x8101020182028202018382014c5477656c76653132313231328202018204008181
820150efa4b5ac0108e3816c5606479801bc04
A.3.4.3. Representations A.3.4.3. Representations
The BCB wrapping this abstract security block is as follows. The complete BCB is as follows.
[ [
12, / type code / 12, / type code /
4, / block number / 4, / block number /
1, / flags - block must be replicated in every fragment / 1, / flags - block must be replicated in every fragment /
0, / CRC type / 0, / CRC type /
h'8101020182028202018382014c5477656c766531323132313282020182040081 h'8101020182028202018382014c5477656c766531323132313282020182040081
820150da08f4d8936024ad7c6b3b800e73dd97', 81820150efa4b5ac0108e3816c5606479801bc04'
] ]
Figure 21: Example 3: BCB (CBOR Diagnostic Notation) Figure 21: Example 3 - BCB (CBOR Diagnostic Notation)
The CBOR encoding of the BCB block is 0x850c0401005833810102018202820 The CBOR encoding of the BCB block is:
2018382014c5477656c766531323132313282020182040081820150da08f4d8936024
ad7c6b3b800e73dd97. 0x850c04010058348101020182028202018382014c5477656c766531323132313282
02018204008181820150efa4b5ac0108e3816c5606479801bc04
A.3.5. Final Bundle A.3.5. Final Bundle
The CBOR encoding of the full output bundle, with the BIB and BCB The CBOR encoding of the full output bundle, with the BIB and BCB
added is: 0x9f88070000820282010282028202018202820201820018281a000f424 added is:
0850b030000585a820002010182028203008282010582030082820158208e059b8e71
f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8e
ba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80850c04010058
338101020182028202018382014c5477656c766531323132313282020182040081820
150da08f4d8936024ad7c6b3b800e73dd9785070200004319012c850101000058203a
09c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff.
A.4. Example 4: Security Blocks with Full Scope 0x9f88070000820282010282028202018202820201820018281a000f4240850b0300
00585c8200020101820282030082820105820300828182015820cac6ce8e4c5dae57
988b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9
7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596850c0401005834
8101020182028202018382014c5477656c7665313231323132820201820400818182
0150efa4b5ac0108e3816c5606479801bc0485070200004319012c85010100005823
3a09c1e63fe23a7f66a59c7303837241e070b02619fc59c5214a22f08cd70795e73e
9aff
A.4. Example 4 - Security Blocks with Full Scope
This example shows the addition of a BIB and BCB to a sample bundle. 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 A BIB is added to provide integrity over the payload block, and a BCB
is added for confidentiality over the payload and BIB. is added for confidentiality over the payload and BIB.
The integrity scope and additional authentication data will bind the The integrity scope and additional authentication data will bind the
primary block, target header, and the security header. primary block, target header, and the security header.
A.4.1. Original Bundle A.4.1. Original Bundle
skipping to change at line 2225 skipping to change at line 2308
blocks have been added. blocks have been added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block | 1 | 1 | | Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 22: Example 4: Original Bundle Figure 22: Example 4 - Original Bundle
A.4.1.1. Primary Block A.4.1.1. Primary Block
The primary block used in this example is identical to the primary The primary block used in this example is identical to the primary
block presented for Example 1 in Appendix A.1.1.1. block presented for Example 1 in Appendix A.1.1.1.
In summary, the CBOR encoding of the primary block is In summary, the CBOR encoding of the primary block is:
0x88070000820282010282028202018202820201820018281a000f4240.
0x88070000820282010282028202018202820201820018281a000f4240
A.4.1.2. Payload Block A.4.1.2. Payload Block
The payload block used in this example is identical to the payload The payload block used in this example is identical to the payload
block presented for Example 1 in Appendix A.1.1.2. block presented for Example 1 in Appendix A.1.1.2.
In summary, the CBOR encoding of the payload block is 0x8501010000582 In summary, the CBOR encoding of the payload block is:
052656164792047656e657261746520612033322062797465207061796c6f6164.
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
A.4.1.3. Bundle CBOR Representation A.4.1.3. Bundle CBOR Representation
A BPv7 bundle is represented as an indefinite-length array consisting A BPv7 bundle is represented as an indefinite-length array consisting
of the blocks comprising the bundle, with a terminator character at of the blocks comprising the bundle, with a terminator character at
the end. the end.
The CBOR encoding of the original bundle is 0x9f880700008202820102820 The CBOR encoding of the original bundle is:
28202018202820201820018281a000f42408501010000582052656164792047656e65
7261746520612033322062797465207061796c6f6164ff. 0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
A.4.2. Security Operation Overview A.4.2. Security Operation Overview
This example provides: This example provides:
* a BIB with the BIB-HMAC-SHA2 security context to provide an * a BIB with the BIB-HMAC-SHA2 security context to provide an
integrity mechanism over the payload block. integrity mechanism over the payload block.
* a BCB with the BCB-AES-GCM security context to provide a * a BCB with the BCB-AES-GCM security context to provide a
confidentiality mechanism over the payload block and BIB. confidentiality mechanism over the payload block and BIB.
The following diagram shows the resulting bundle after the security The following diagram shows the resulting bundle after the security
blocks are added. blocks are added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Integrity Block (Encrypted) | 11 | 3 | | Block Integrity Block (Encrypted) | 11 | 3 |
| OP(bib-integrity, target=1) | | | | OP(bib-integrity, target=1) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Confidentiality Block | 12 | 2 | | Block Confidentiality Block | 12 | 2 |
| OP(bcb-confidentiality, targets=1, 3) | | | | OP(bcb-confidentiality, targets=1, 3) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 1 | 1 | | Payload Block (Encrypted) | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 23: Example 4: Resulting Bundle Figure 23: Example 4 - Resulting Bundle
A.4.3. Bundle Integrity Block A.4.3. Block Integrity Block
In this example, a BIB is used to carry an integrity signature over In this example, a BIB is used to carry an integrity signature over
the payload block. The IPPT contains the payload block block-type- the payload block. The IPPT contains the block-type-specific data of
specific data, primary block data, the payload block header, and the the payload block, the primary block data, the payload block header,
BIB header. That is, all additional headers are included in the and the BIB header. That is, all additional headers are included in
IPPT. the IPPT.
A.4.3.1. Configuration, Parameters, and Results A.4.3.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters For this example, the following configuration and security context
are used to generate the security results indicated. parameters are used to generate the security results indicated.
This BIB has a single target and includes a single security result: This BIB has a single target and includes a single security result:
the calculated signature over the Payload block. the calculated signature over the Payload block.
Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
SHA Variant: HMAC 384/384 SHA Variant: HMAC 384/384
Scope Flags: 0x07 (all additional headers) Scope Flags: 0x07 (all additional headers)
Primary Block Data: h'88070000820282010282028202018202 Primary Block Data: h'88070000820282010282028202018202
820201820018281a000f4240 820201820018281a000f4240'
Payload Data: h'52656164792047656e65726174652061 Payload Data: h'526561647920746f2067656e65726174
2033322062797465207061796c6f6164' 6520612033322d62797465207061796c
Payload Header: h'85010100005820' 6f6164'
BIB Header: h'850b0300005845' Payload Header: h'010100'
Payload Signature: h'07c84d929f83bee4690130729d77a1bd BIB Header: h'0b0300'
da9611cd6598e73d0659073ea74e8c27 IPPT: h'07880700008202820102820282020182
523b02193cb8ba64be58dbc556887aca 02820201820018281a000f4240010100
0b03005823526561647920746f206765
6e657261746520612033322d62797465
207061796c6f6164'
Payload Signature: h'f75fe4c37f76f046165855bd5ff72fbf
d4e3a64b4695c40e2b787da005ae819f
0a2e30a2e8b325527de8aefb52e73d71,
Figure 24: Example 4: Configuration, Parameters, and Results for Figure 24: Example 4 - Configuration, Parameters, and Results for
the BIB the BIB
A.4.3.2. Abstract Security Block A.4.3.2. Abstract Security Block
The abstract security block structure of the BIB's block-type- The abstract security block structure of the BIB's block-type-
specific-data field for this application is as follows. specific data field for this application is as follows.
[1], / Security Target - Payload block / [1], / Security Target - Payload block /
1, / Security Context ID - BIB-HMAC-SHA2 / 1, / Security Context ID - BIB-HMAC-SHA2 /
1, / Security Context Flags - Parameters Present / 1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 / [2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 2 Parameters / [ / Security Parameters - 2 Parameters /
[1, 6], / SHA Variant - HMAC 384/384 / [1, 6], / SHA Variant - HMAC 384/384 /
[3, 0x07] / Scope Flags - All additional headers in the SHA Hash / [3, 0x07] / Scope Flags - All additional headers /
], ],
[ / Security Results: 1 Result / [ / Security Results: 1 Result /
[1, h'07c84d929f83bee4690130729d77a1bdda9611cd6598e73d [ / Target 1 Results /
0659073ea74e8c27523b02193cb8ba64be58dbc556887aca'] [1, h'f75fe4c37f76f046165855bd5ff72fbf / MAC /
d4e3a64b4695c40e2b787da005ae819f
0a2e30a2e8b325527de8aefb52e73d71']
]
] ]
Figure 25: Example 4: BIB Abstract Security Block (CBOR Figure 25: Example 4 - BIB Abstract Security Block (CBOR
Diagnostic Notation) Diagnostic Notation)
The CBOR encoding of the BIB block-type-specific-data field (the The CBOR encoding of the BIB block-type-specific data field (the
abstract security block) is 0x810101018202820201828201068203078182015 abstract security block) is:
83007c84d929f83bee4690130729d77a1bdda9611cd6598e73d0659073ea74e8c2752
3b02193cb8ba64be58dbc556887aca. 0x81010101820282020182820106820307818182015830f75fe4c37f76f046165855
bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8aefb52
e73d71
A.4.3.3. Representations A.4.3.3. Representations
The BIB wrapping this abstract security block is as follows. The complete BIB is as follows.
[ [
11, / type code / 11, / type code /
3, / block number / 3, / block number /
0, / flags / 0, / flags /
0, / CRC type / 0, / CRC type /
h'81010101820282020182820106820307818201583007c84d929f83bee4690130 h'81010101820282020182820106820307818182015830f75fe4c37f76f0461658
729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58db 55bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8
c556887aca', aefb52e73d71'
] ]
Figure 26: Example 4: BIB (CBOR Diagnostic Notation) Figure 26: Example 4 - BIB (CBOR Diagnostic Notation)
The CBOR encoding of the BIB block is 0x850b0300005845810101018202820 The CBOR encoding of the BIB block is:
20182820106820307818201583007c84d929f83bee4690130729d77a1bdda9611cd65
98e73d0659073ea74e8c27523b02193cb8ba64be58dbc556887aca.
A.4.4. Bundle Confidentiality Block 0x850b030000584681010101820282020182820106820307818182015830f75fe4c3
7f76f046165855bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b3
25527de8aefb52e73d71
A.4.4. Block Confidentiality Block
In this example, a BCB is used encrypt the payload block and the BIB In this example, a BCB is used encrypt the payload block and the BIB
that provides integrity over the payload. that provides integrity over the payload.
A.4.4.1. Configuration, Parameters, and Results A.4.4.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters For this example, the following configuration and security context
are used to generate the security results indicated. parameters are used to generate the security results indicated.
This BCB has two targets: the payload block and BIB. Four security This BCB has two targets: the payload block and BIB. Four security
results are generated: cipher text that replaces the plain text results are generated: ciphertext that replaces the plaintext block-
block-type-specific data of the payload block, cipher text to encrypt type-specific data of the payload block, ciphertext to encrypt the
the BIB, and authentication tags for both the payload block and BIB. BIB, and authentication tags for both the payload block and BIB.
Key: h'71776572747975696f70617364666768 Key: h'71776572747975696f70617364666768
71776572747975696f70617364666768' 71776572747975696f70617364666768'
IV: h'5477656c7665313231323132' IV: h'5477656c7665313231323132'
AES Variant: A256GCM AES Variant: A256GCM
Scope Flags: 0x07 (All additional headers) Scope Flags: 0x07 (All additional headers)
Payload Data: h'52656164792047656e65726174652061 Payload Data: h'526561647920746f2067656e65726174
2033322062797465207061796c6f6164' 6520612033322d62797465207061796c
6f6164'
BIB Data: h'81010101820282020182820106820307 BIB Data: h'81010101820282020182820106820307
818201583007c84d929f83bee4690130 818182015830f75fe4c37f76f0461658
729d77a1bdda9611cd6598e73d065907 55bd5ff72fbfd4e3a64b4695c40e2b78
3ea74e8c27523b02193cb8ba64be58db 7da005ae819f0a2e30a2e8b325527de8
c556887aca aefb52e73d71'
BIB Primary Block Data: h'88070000820282010282028202018202
Authentication Tag: h'c95ed4534769b046d716e1cdfd00830e' 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 Block Payload Block
Authentication Tag: h'0e365c700e4bb19c0d991faff5345aff' Authentication Tag: h'd2c51cb2481792dae8b21d848cede99b'
Payload Ciphertext: h'90eab64575930498d6aa654107f15e96 BIB
319bb227706000abc8fcac3b9bb9c87e' Authentication Tag: h'220ffc45c8a901999ecc60991dd78b29'
Payload Ciphertext: h'90eab6457593379298a8724e16e61f83
7488e127212b59ac91f8a86287b7d076
30a122'
BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0 BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0
902a815f221ebc837a134efc13bfa82a 902902064a2983910c4fb2340790bf42
2d5d317747da3eb54acef4ca839bd961 0a7d1921d5bf7c4721e02ab87a93ab1e
487284404259b60be12b8aed2f3e8a36 0b75cf62e4948727c8b5dae46ed2af05
2836529f66' 439b88029191'
Figure 27: Example 4: Configuration, Parameters, and Results for Figure 27: Example 4 - Configuration, Parameters, and Results for
the BCB the BCB
A.4.4.2. Abstract Security Block A.4.4.2. Abstract Security Block
The abstract security block structure of the BCB's block-type- The abstract security block structure of the BCB's block-type-
specific-data field for this application is as follows. specific data field for this application is as follows.
[3, 1], / Security Targets / [3, 1], / Security Targets /
2, / Security Context ID - BCB-AES-GCM / 2, / Security Context ID - BCB-AES-GCM /
1, / Security Context Flags - Parameters Present / 1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 / [2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 3 Parameters / [ / Security Parameters - 3 Parameters /
[1, h'5477656c7665313231323132'], / Initialization Vector / [1, h'5477656c7665313231323132'], / Initialization Vector /
[2, 3], / AES Variant - AES 256 / [2, 3], / AES Variant - AES 256 /
[4, 0x07] / Scope Flags - All headers in SHA hash / [4, 0x07] / Scope Flags - All headers in SHA hash /
], ],
[ / Security Results: 2 Results / [ / Security Results: 2 Results /
[1, h'c95ed4534769b046d716e1cdfd00830e'], / BIB Auth. Tag / [
[1, h'0e365c700e4bb19c0d991faff5345aff'] / Payload Auth. Tag / [1, h'220ffc45c8a901999ecc60991dd78b29'] / BIB Auth. Tag /
],
[
[1, h'd2c51cb2481792dae8b21d848cede99b'] / Payload Auth. Tag /
]
] ]
Figure 28: Example 4: BCB Abstract Security Block (CBOR Figure 28: Example 4 - BCB Abstract Security Block (CBOR
Diagnostic Notation) Diagnostic Notation)
The CBOR encoding of the BCB block-type-specific-data field (the The CBOR encoding of the BCB block-type-specific data field (the
abstract security block) is 0x820301020182028202018382014c5477656c766 abstract security block) is:
531323132313282020382040782820150c95ed4534769b046d716e1cdfd00830e8201
500e365c700e4bb19c0d991faff5345aff. 0x820301020182028202018382014c5477656c766531323132313282020382040782
81820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792dae8b2
1d848cede99b
A.4.4.3. Representations A.4.4.3. Representations
The BCB wrapping this abstract security block is as follows. The complete BCB is as follows.
[ [
12, / type code / 12, / type code /
2, / block number / 2, / block number /
1, / flags - block must be replicated in every fragment / 1, / flags - block must be replicated in every fragment /
0, / CRC type / 0, / CRC type /
h'820301020182028202018382014c5477656c7665313231323132820203820407 h'820301020182028202018382014c5477656c7665313231323132820203820407
82820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d 8281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792
991faff5345aff', dae8b21d848cede99b'
] ]
Figure 29: Example 4: BCB (CBOR Diagnostic Notation) Figure 29: Example 4 - BCB (CBOR Diagnostic Notation)
The CBOR encoding of the BCB block is 0x850c0201005847820301020182028 The CBOR encoding of the BCB block is:
202018382014c5477656c766531323132313282020382040782820150c95ed4534769
b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff. 0x850c0201005849820301020182028202018382014c5477656c7665313231323132
8202038204078281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51c
b2481792dae8b21d848cede99b
A.4.5. Final Bundle A.4.5. Final Bundle
The CBOR encoding of the full output bundle, with the security blocks The CBOR encoding of the full output bundle, with the security blocks
added and payload block and BIB encrypted is: added and payload block and BIB encrypted is:
0x9f88070000820282010282028202018202820201820018281a000f4240850b03000 0x9f88070000820282010282028202018202820201820018281a000f4240850b0300
05845438ed6208eb1c1ffb94d952175167df0902a815f221ebc837a134efc13bfa82a 005846438ed6208eb1c1ffb94d952175167df0902902064a2983910c4fb2340790bf
2d5d317747da3eb54acef4ca839bd961487284404259b60be12b8aed2f3e8a3628365 420a7d1921d5bf7c4721e02ab87a93ab1e0b75cf62e4948727c8b5dae46ed2af0543
29f66850c0201005847820301020182028202018382014c5477656c76653132313231 9b88029191850c0201005849820301020182028202018382014c5477656c76653132
3282020382040782820150c95ed4534769b046d716e1cdfd00830e8201500e365c700 313231328202038204078281820150220ffc45c8a901999ecc60991dd78b29818201
e4bb19c0d991faff5345aff8501010000582090eab64575930498d6aa654107f15e96 50d2c51cb2481792dae8b21d848cede99b8501010000582390eab6457593379298a8
319bb227706000abc8fcac3b9bb9c87eff. 724e16e61f837488e127212b59ac91f8a86287b7d07630a122ff
Appendix B. CDDL Expression Appendix B. CDDL Expression
For informational purposes, Brian Sipos has kindly provided an For informational purposes, this section contains an expression of
expression of the IPPT and AAD structures using the Concise Data the IPPT and AAD structures using the Concise Data Definition
Definition Language (CDDL). That CDDL expression is presented below. Language (CDDL).
NOTES: NOTES:
* Wherever the CDDL expression is in disagreement with the textual * Wherever the CDDL expression is in disagreement with the textual
representation of the security block specification presented in representation of the security block specification presented in
earlier sections of this document, the textual representation earlier sections of this document, the textual representation
rules. rules.
* The structure of BP bundles and BPSec security blocks are provided * The structure of BP bundles and BPSec security blocks are provided
by other specifications; this appendix only provides the CDDL by other specifications; this appendix only provides the CDDL
skipping to change at line 2505 skipping to change at line 2627
) )
; Encoded as a CBOR sequence ; Encoded as a CBOR sequence
AAD-list = [ AAD-list = [
AAD-structure AAD-structure
] ]
; Encoded as a CBOR sequence ; Encoded as a CBOR sequence
IPPT-list = [ IPPT-list = [
AAD-structure, AAD-structure,
target-btsd: bstr ; block-type-specific-data of the target block. target-btsd: bstr ; block-type-specific data of the target block.
] ]
AAD-structure = ( AAD-structure = (
scope, scope,
? primary-block, ; present if has-primary-ctx flag set ? primary-block, ; present if has-primary-ctx flag set
? block-metadata, ; present if has-target-ctx flag set ? block-metadata, ; present if has-target-ctx flag set
? block-metadata, ; present if has-security-ctx flag set ? block-metadata, ; present if has-security-ctx flag set
) )
; Selected fields of a canonical block ; Selected fields of a canonical block
skipping to change at line 2529 skipping to change at line 2651
block-control-flags, block-control-flags,
) )
Figure 30: IPPT and AAD Expressions Figure 30: IPPT and AAD Expressions
Acknowledgments Acknowledgments
Amy Alford of the Johns Hopkins University Applied Physics Laboratory Amy Alford of the Johns Hopkins University Applied Physics Laboratory
contributed useful review and analysis of these security contexts. contributed useful review and analysis of these security contexts.
Brian Sipos kindly provided the CDDL expression in Appendix B.
Authors' Addresses Authors' Addresses
Edward J. Birrane, III Edward J. Birrane, III
The Johns Hopkins University Applied Physics Laboratory The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd. 11100 Johns Hopkins Rd.
Laurel, MD 20723 Laurel, MD 20723
United States of America United States of America
Phone: +1 443 778 7423 Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu Email: Edward.Birrane@jhuapl.edu
 End of changes. 263 change blocks. 
613 lines changed or deleted 737 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/