rfc9173.original.xml   rfc9173.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?>
<!-- generate a table of contents --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dtn-bpsec-de
<?rfc symrefs="yes"?> fault-sc-11" number="9173" ipr="trust200902" obsoletes="" submissionType="IETF"
<!-- use anchors instead of numbers for references --> category="std" consensus="true" updates="" xml:lang="en" tocInclude="true" symRe
<?rfc sortrefs="yes" ?> fs="true" sortRefs="true" version="3">
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-dtn-bpsec-default-sc-11" ipr="trust200902" obsoletes="" submissionType="IETF"
updates="" xml:lang="en" tocInclude="true" symRefs="true" consensus="true" sort
Refs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.9.0 --> <!-- xml2rfc v2v3 conversion 3.9.0 -->
<front> <front>
<title>BPSec Default Security Contexts</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-dtn-bpsec-default-sc-11" <title abbrev="BPSec Default Security Contexts">Default Security Contexts fo
/> r Bundle Protocol Security (BPSec)</title>
<author fullname="Edward J. Birrane, III" initials="E.J." surname="Birrane"> <seriesInfo name="RFC" value="9173"/>
<author initials="E." surname="Birrane, III" fullname="Edward J. Birrane, II
I">
<organization abbrev="JHU/APL">The Johns Hopkins University Applied <organization abbrev="JHU/APL">The Johns Hopkins University Applied
Physics Laboratory</organization> Physics Laboratory</organization>
<address> <address>
<postal> <postal>
<street>11100 Johns Hopkins Rd.</street> <street>11100 Johns Hopkins Rd.</street>
<city>Laurel</city> <city>Laurel</city>
<region>MD</region> <region>MD</region>
<code>20723</code> <code>20723</code>
<country>US</country> <country>US</country>
</postal> </postal>
skipping to change at line 68 skipping to change at line 62
<street>11100 Johns Hopkins Rd.</street> <street>11100 Johns Hopkins Rd.</street>
<city>Laurel</city> <city>Laurel</city>
<region>MD</region> <region>MD</region>
<code>20723</code> <code>20723</code>
<country>US</country> <country>US</country>
</postal> </postal>
<phone>+1 240 592 3704</phone> <phone>+1 240 592 3704</phone>
<email>Sarah.Heiner@jhuapl.edu</email> <email>Sarah.Heiner@jhuapl.edu</email>
</address> </address>
</author> </author>
<date month="July" day="25" year="2021"/> <date month="January" year="2022"/>
<!-- Meta-data --> <!-- Meta-data -->
<area>General</area> <area>General</area>
<workgroup>Delay-Tolerant Networking</workgroup> <workgroup>Delay-Tolerant Networking</workgroup>
<keyword>security</keyword> <keyword>security</keyword>
<keyword>bundle</keyword> <keyword>bundle</keyword>
<keyword>integrity</keyword> <keyword>integrity</keyword>
<keyword>confidentiality</keyword> <keyword>confidentiality</keyword>
<abstract> <abstract>
<t> <t>
This document defines default integrity and confidentiality security This document defines default integrity and confidentiality security
contexts that can be used with the Bundle Protocol Security Protocol contexts that can be used with Bundle Protocol Security
(BPSec) implementations. These security contexts are intended to be (BPSec) implementations. These security contexts are intended to be
used for both testing the interoperability of BPSec implementations and for providing used both for testing the interoperability of BPSec implementations and for providing
basic security operations when no other security contexts are defined basic security operations when no other security contexts are defined
or otherwise required for a network. or otherwise required for a network.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" toc="default" numbered="true"> <section anchor="intro" toc="default" numbered="true">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
The Bundle Protocol Security Protocol (BPSec) The Bundle Protocol Security (BPSec) specification
<xref target="I-D.ietf-dtn-bpsec" format="default"/> specification prov <xref target="RFC9172" format="default"/> provides inter-bundle
ides inter-bundle
integrity and confidentiality operations for networks deploying the integrity and confidentiality operations for networks deploying the
Bundle Protocol (BP) <xref target="I-D.ietf-dtn-bpbis" format="default" />. BPSec defines Bundle Protocol (BP) <xref target="RFC9171" format="default"/>. BPSec d efines
BP extension blocks to carry security information produced under the BP extension blocks to carry security information produced under the
auspices of some security context. auspices of some security context.
</t> </t>
<t> <t>
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 service and one for a confidentiality service) for populating
BPSec Block Integrity Blocks (BIBs) and Block Confidentiality Blocks BPSec 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 terminology associated with BP and BPSec, as these security
contexts are used with BPSec security blocks and other BP blocks contexts are used with BPSec security blocks and other BP blocks
carried within BP bundles. carried within BP bundles.
</t> </t>
<t> <t>
These contexts generate information that MUST be encoded using These contexts generate information that <bcp14>MUST</bcp14> be encoded
the CBOR specification documented in <xref target="RFC8949" format="def using
ault"/>. the Concise Binary Object Representation (CBOR) specification documente
d in <xref target="RFC8949" format="default"/>.
</t> </t>
</section> </section>
<section anchor="term" toc="default" numbered="true"> <section anchor="term" toc="default" numbered="true">
<name>Requirements Language</name> <name>Requirements Language</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
described in BCP 14 <xref target="RFC2119" format="default"/> <xref tar RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
get="RFC8174" format="default"/> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
when, and only when, they appear in all capitals, as shown here. be interpreted as
</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default" anchor="first-context">
<name>Integrity Security Context BIB-HMAC-SHA2</name> <name>Integrity Security Context BIB-HMAC-SHA2</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Overview</name> <name>Overview</name>
<t> <t>
The BIB-HMAC-SHA2 security context provides a keyed-hash The BIB-HMAC-SHA2 security context provides a keyed-hash
Message Authentication Code (MAC) over a Message Authentication Code (MAC) over a
set of plain text information. This context uses the Secure set of plaintext information. This context uses the Secure
Hash Algorithm 2 (SHA-2) discussed in <xref target="SHS" format="def ault"/> combined Hash Algorithm 2 (SHA-2) discussed in <xref target="SHS" format="def ault"/> combined
with the HMAC keyed hash discussed in <xref target="RFC2104" format= "default"/>. The combination with the Hashed Message Authentication Code (HMAC) keyed hash discus sed in <xref target="RFC2104" format="default"/>. The combination
of HMAC and SHA-2 as the integrity mechanism for this security of HMAC and SHA-2 as the integrity mechanism for this security
context was selected for two reasons: context was selected for two reasons:
</t> </t>
<ol spacing="normal" type="1"><li> The use of symmetric keys allows this security context to <ol spacing="normal" type="1"><li> The use of symmetric keys allows this security context to
be used in places where an asymmetric-key infrastructure (such a s a be used in places where an asymmetric-key infrastructure (such a s a
public key infrastructure) might be impractical. public key infrastructure) might be impractical.
</li> </li>
<li> <li>
The combination HMAC-SHA2 represents a well-supported and well-u nderstood The combination HMAC-SHA2 represents a well-supported and well-u nderstood
integrity mechanism with multiple implementations available. integrity mechanism with multiple implementations available.
</li> </li>
</ol> </ol>
<t> <t>
BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on
the supported length of the SHA-2 hash value. These variants the supported length of the SHA-2 hash value. These variants
correspond to "HMAC 256/256", "HMAC 384/384", and "HMAC 512/512" as correspond to HMAC 256/256, HMAC 384/384, and HMAC 512/512 as
defined in <xref target="RFC8152" format="default"/> Table 7: HMAC A defined in Table 7 ("HMAC Algorithm Values") of <xref target="RFC815
lgorithm Values. 2" format="default"/>.
The selection of which variant is used by this context is The selection of which variant is used by this context is
provided as a security context parameter. provided as a security context parameter.
</t> </t>
<t> <t>
The output of the HMAC MUST be equal to the size of the SHA2 The output of the HMAC <bcp14>MUST</bcp14> be equal to the size of t he SHA2
hashing function: 256 bits for SHA-256, 384 bits for SHA-384, and hashing function: 256 bits for SHA-256, 384 bits for SHA-384, and
512 bits for SHA-512. 512 bits for SHA-512.
</t> </t>
<t> <t>
The BIB-HMAC-SHA2 security context MUST have the security context The BIB-HMAC-SHA2 security context <bcp14>MUST</bcp14> have the secu rity context
identifier specified in <xref target="sc_ids" format="default"/>. identifier specified in <xref target="sc_ids" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Scope</name> <name>Scope</name>
<t> <t>
The scope of BIB-HMAC-SHA2 is the set of information used 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 to produce the plaintext over which a keyed hash is calculated. This
plain text is termed the "Integrity Protected Plain Text" (IPPT). The plaintext is termed the "Integrity-Protected Plaintext (IPPT)". The
content of the IPPT is constructed as the concatenation of information content of the IPPT is constructed as the concatenation of information
whose integrity is being preserved from the BIB-HMAC-SHA2 security whose integrity is being preserved from the BIB-HMAC-SHA2 security
source to its security acceptor. There are five types of information source to its security acceptor. There are five types of information
that can be used in the generation of the IPPT, based on that can be used in the generation of the IPPT, based on
how broadly the concept of integrity is being applied. These how broadly the concept of integrity is being applied. These
five types of information, whether they are required, and why five types of information, whether they are required, and why
they are important for integrity, are discussed as follows. they are important for integrity are discussed as follows.
</t> </t>
<dl newline="true" spacing="normal" indent="4">
<dl newline="true" spacing="normal" indent="3">
<dt>Security target contents</dt> <dt>Security target contents</dt>
<dd> <dd>
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 pr otects target <bcp14>MUST</bcp14> be included in the IPPT. Including this information protects
the security target data and is considered the minimal, required the security target data and is considered the minimal, required
set of information for an integrity service on the security set of information for an integrity service on the security
target. target.
</dd> </dd>
<dt>IPPT Scope</dt> <dt>IPPT scope</dt>
<dd> <dd>
The determination of which optional types of information were The determination of which optional types of information were
used when constructing the IPPT MUST, itself, always be included used when constructing the IPPT <bcp14>MUST</bcp14> always be incl uded
in the IPPT. Including this information ensures that the scope in the IPPT. Including this information ensures that the scope
of the IPPT construction at a security source matches the scope of of the IPPT construction at a security source matches the scope of
the IPPT construction at security verifiers and security acceptors . the IPPT construction at security verifiers and security acceptors .
</dd> </dd>
<dt>Primary block</dt> <dt>Primary block</dt>
<dd> <dd>
<t> <t>
The primary block identifies a bundle and, once The primary block identifies a bundle, and once
created, the contents of this block are immutable. Changes to created, the contents of this block are immutable. Changes to
the primary block associated with the security target indicate the primary block associated with the security target indicate
that the security target (and BIB) might no longer be in the that the security target (and BIB) might no longer be in the
correct bundle. correct bundle.
</t> </t>
<t> <t>
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 associated with the bundle primary block is included in the
keyed hash carried by the BIB. keyed hash carried by the BIB.
</t> </t>
<t> <t>
Including this information in the IPPT protects the integrity Including this information in the IPPT protects the integrity
of the association of the security target with a specific bundle. of the association of the security target with a specific bundle.
</t> </t>
</dd> </dd>
<dt>Security target other fields</dt> <dt>Other fields of the security target</dt>
<dd> <dd>
<t> <t>
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 information changes how the security target is treated by nodes
in the network even when the in the network even when the
"user data" of the security target are otherwise unchanged. "user data" of the security target are otherwise unchanged.
</t> </t>
<t> <t>
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.
</t> </t>
<t> <t>
Including this information in the IPPT protects the integrity Including this information in the IPPT protects the integrity
of the policy and identification of the security target data. of the policy and identification of the security target data.
</t> </t>
</dd> </dd>
<dt>BIB other fields</dt> <dt>Other fields of the BIB</dt>
<dd> <dd>
<t> <t>
The other fields of the BIB include block identification The other fields of the BIB include block identification
and processing information. and processing information.
Changing this information changes how the BIB Changing this information changes how the BIB
is treated by nodes in the network, even when other aspects of the is treated by nodes in the network, even when other aspects of the
BIB are unchanged. BIB are unchanged.
</t> </t>
<t> <t>
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 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 BIB has been modified. handling the BIB has been modified.
</t> </t>
<t> <t>
Including this information in the IPPT protects the integrity Including this information in the IPPT protects the integrity
of the policy and identification of the security service in the bu ndle. of the policy and identification of the security service in the bu ndle.
</t> </t>
<aside>
<t> <t>
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 IPPT
because these parameters, by definition, are required to verify or because these parameters, by definition, are required to verify or
accept the security service. Successful verification at security accept the security service. Successful verification at security
verifiers and security acceptors implies that these parameters verifiers and security acceptors implies that these parameters
were unchanged since being specified at the security source. were unchanged since being specified at the security source.
This is the case because keys cannot be re-used across security This is the case because keys cannot be reused across security
contexts, and because the integrity scope flags used to define contexts and because the integrity scope flags used to define
the IPPT are included in the IPPT itself. the IPPT are included in the IPPT itself.
</t> </t>
</aside>
</dd> </dd>
</dl> </dl>
<t> <t>
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.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Parameters</name> <name>Parameters</name>
<t> <t>
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.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>SHA Variant</name> <name>SHA Variant</name>
<t> <t>
This optional parameter identifies which variant of the SHA-2 This optional parameter identifies which variant of the SHA-2
algorithm is to be used in the generation of the authentication code . algorithm is to be used in the generation of the authentication code .
</t> </t>
<t> <t>
This value MUST be encoded as a CBOR unsigned integer. This value <bcp14>MUST</bcp14> be encoded as a CBOR unsigned integer .
</t> </t>
<t> <t>
Valid values for this parameter are as follows. Valid values for this parameter are as follows.
</t> </t>
<t keepWithNext="true">
SHA Variant Parameter Values
</t>
<table align="center" anchor="sha_var"> <table align="center" anchor="sha_var">
<name>SHA Variant Parameter Values</name>
<thead> <thead>
<tr> <tr>
<th align="center">Value</th> <th align="center">Value</th>
<th align="center">Description</th> <th align="center">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">5</td> <td align="center">5</td>
<td align="center">HMAC 256/256 as defined in <xref target="RFC8 152" format="default"/> Table 7: HMAC Algorithm Values</td> <td>HMAC 256/256 as defined in Table 7 ("HMAC Algorithm Values") of <xref target="RFC8152" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="center">6</td> <td align="center">6</td>
<td align="center">HMAC 384/384 as defined in <xref target="RFC8 152" format="default"/> Table 7: HMAC Algorithm Values</td> <td>HMAC 384/384 as defined in Table 7 ("HMAC Algorithm Values") of <xref target="RFC8152" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="center">7</td> <td align="center">7</td>
<td align="center">HMAC 512/512 as defined in <xref target="RFC8 152" format="default"/> Table 7: HMAC Algorithm Values</td> <td>HMAC 512/512 as defined in Table 7 ("HMAC Algorithm Values") of <xref target="RFC8152" format="default"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
When not provided, implementations SHOULD assume a value of 6 When not provided, implementations <bcp14>SHOULD</bcp14> assume a va lue 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, verifie rs, established by local security policy at the security source, verifie rs,
or acceptor of this integrity service. or acceptor of this integrity service.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Wrapped Key</name> <name>Wrapped Key</name>
<t> <t>
This optional parameter contains the output of the AES key wrap This optional parameter contains the output of the AES key wrap funct
authenticated encryption function (KW-AE) as defined in <xref target ion as defined in <xref target="RFC3394" format="default"/>. Specifically, this
="RFC5649" format="default"/>. Specifically, parameter holds the ciphertext produced when running this key wrap algorithm wi
this parameter holds the cipher text produced when running the KW-AE th the
algorithm input string being the symmetric HMAC
with the input string being the symmetric HMAC
key used to generate the security results present in the security bl ock. key used to generate the security results present in the security bl ock.
The value of this parameter is used as input to the AES key wrap aut henticated The value of this parameter is used as input to the AES key wrap aut henticated
decryption function (KW-AD) at security verifiers and security accep tors to determine decryption function at security verifiers and security acceptors to determine
the symmetric HMAC key needed for the proper validation of the secur ity results the symmetric HMAC key needed for the proper validation of the secur ity results
in the security block. in the security block.
</t> </t>
<t> <t>
This value MUST be encoded as a CBOR byte string. This value <bcp14>MUST</bcp14> be encoded as a CBOR byte string.
</t> </t>
<t> <t>
If this parameter is not present then security verifiers If this parameter is not present, then security verifiers
and acceptors MUST determine the proper key as a function of their l and acceptors <bcp14>MUST</bcp14> determine the proper key as a func
ocal BPSec policy tion of their local BPSec policy
and configuration. and configuration.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Integrity Scope Flags</name> <name>Integrity Scope Flags</name>
<t> <t>
This optional parameter contains a series of flags that describe This optional parameter contains a series of flags that describe
what information is to be included with the block-type-specific data what information is to be included with the block-type-specific data
when constructing the IPPT value. when constructing the IPPT value.
</t> </t>
<t> <t>
This value MUST be represented as a CBOR unsigned This value <bcp14>MUST</bcp14> be represented as a CBOR unsigned
integer, the value of which MUST be processed as a 16-bit field. integer, the value of which <bcp14>MUST</bcp14> be processed as a 16
The maximum value of this field, as a CBOR unsigned integer, MUST be -bit field.
The maximum value of this field, as a CBOR unsigned integer, <bcp14>
MUST</bcp14> be
65535. 65535.
</t> </t>
<t>When not provided, implementations <bcp14>SHOULD</bcp14> assume a va
lue of 7 (indicating all assigned fields), unless an alternate default is establ
ished by local security policy at the security source, verifier, or acceptor of
this integrity service.
</t>
<t> <t>
Implementations MUST set reserved and unassigned bits in this Implementations <bcp14>MUST</bcp14> set reserved and unassigned bits in this
field to 0 when constructing these flags at a security source. field to 0 when constructing these flags at a security source.
Once set, the value of this field MUST NOT be altered until the Once set, the value of this field <bcp14>MUST NOT</bcp14> be altered until the
security service is completed at the security acceptor in the security service is completed at the security acceptor in the
network and removed from the bundle. network and removed from the bundle.
</t> </t>
<t> <t>
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.
</t> </t>
<ul empty="true" spacing="normal">
<li>- Bit 0 (the low-order bit, 0x0001): Primary Block Flag. </li> <dl>
<li>- Bit 1 (0x0002): Target Header Flag.</li> <dt>Bit 0 (the low-order bit, 0x0001):</dt><dd>Include primary block
<li>- Bit 2 (0x0004): Security Header Flag. </li> flag</dd>
<li>- Bits 3-7 are reserved.</li> <dt>Bit 1 (0x0002):</dt><dd>Include target header flag</dd>
<li>- Bits 8-15 are unassigned.</li> <dt>Bit 2 (0x0004):</dt><dd>Include security header flag</dd>
</ul> <dt>Bits 3-7:</dt><dd>Reserved</dd>
<dt>Bits 8-15:</dt><dd>Unassigned</dd>
</dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Enumerations</name> <name>Enumerations</name>
<t> <t>
The BIB-HMAC-SHA2 security context parameters are listed in The BIB-HMAC-SHA2 security context parameters are listed in
<xref target="bib_parm_table" format="default"/>. In this table, the "Parm Id" column <xref target="bib_parm_table" format="default"/>. In this table, the "Parm Id" column
refers to the expected Parameter Identifier described in refers to the expected parameter identifier described in Section
<xref target="I-D.ietf-dtn-bpsec" format="default"/>, Section 3.10 <xref target="RFC9172" section="3.10" sectionFormat="bare">"Paramet
"Parameter er
and Result Identification". and Result Identification"</xref> of <xref target="RFC9172"/>.
</t> </t>
<t> <t>
If the default value column is empty, this indicates that the An empty "Default Value" column indicates that the
security parameter does not have a default value. security context parameter does not have a default value.
</t>
<t keepWithNext="true">
BIB-HMAC-SHA2 Security Parameters
</t> </t>
<table align="center" anchor="bib_parm_table"> <table align="center" anchor="bib_parm_table">
<name>BIB-HMAC-SHA2 Security Context Parameters</name>
<thead> <thead>
<tr> <tr>
<th align="center">Parm Id</th> <th align="center">Parm Id</th>
<th align="center">Parm Name</th> <th>Parm Name</th>
<th align="center">CBOR Encoding Type</th> <th>CBOR Encoding Type</th>
<th align="center">Default Value</th> <th>Default Value</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">1</td> <td align="center">1</td>
<td align="center">SHA Variant</td> <td>SHA Variant</td>
<td align="center">unsigned integer</td> <td>unsigned integer</td>
<td align="center">6</td> <td align="center">6</td>
</tr> </tr>
<tr> <tr>
<td align="center">2</td> <td align="center">2</td>
<td align="center">Wrapped Key</td> <td>Wrapped Key</td>
<td align="center">Byte String</td> <td>byte string</td>
<td align="center"/> <td align="center"/>
</tr> </tr>
<tr> <tr>
<td align="center">3</td> <td align="center">3</td>
<td align="center">Integrity Scope Flags</td> <td>Integrity Scope Flags</td>
<td align="center">unsigned integer</td> <td>unsigned integer</td>
<td align="center">7</td> <td align="center">7</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="bib_results" numbered="true" toc="default"> <section anchor="bib_results" numbered="true" toc="default">
<name>Results</name> <name>Results</name>
<t> <t>
The BIB-HMAC-SHA2 security context results are listed in The BIB-HMAC-SHA2 security context results are listed in
<xref target="bib_res_table" format="default"/>. In this table, the "Result Id" column <xref target="bib_res_table" format="default"/>. In this table, the "Result Id" column
refers to the expected Result Identifier described in refers to the expected result identifier described in Section
<xref target="I-D.ietf-dtn-bpsec" format="default"/>, Section 3.10 <xref target="RFC9172" section="3.10" sectionFormat="bare">"Paramet
"Parameter er
and Result Identification". and Result Identification"</xref> of <xref target="RFC9172"/>.
</t>
<t keepWithNext="true">
BIB-HMAC-SHA2 Security Results
</t> </t>
<table align="center" anchor="bib_res_table"> <table align="center" anchor="bib_res_table">
<name>BIB-HMAC-SHA2 Security Results</name>
<thead> <thead>
<tr> <tr>
<th align="center">Result Id</th> <th align="center">Result Id</th>
<th align="center">Result Name</th> <th align="center">Result Name</th>
<th align="center">CBOR Encoding Type</th> <th align="center">CBOR Encoding Type</th>
<th align="center">Description</th> <th align="center">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">1</td> <td align="center">1</td>
<td align="center">Expected HMAC</td> <td align="center">Expected HMAC</td>
<td align="center">byte string</td> <td align="center">byte string</td>
<td align="center">The output of the HMAC calculation at the secur ity source.</td> <td>The output of the HMAC calculation at the security source.</td >
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="bib_key_mgmt" numbered="true" toc="default"> <section anchor="bib_key_mgmt" numbered="true" toc="default">
<name>Key Considerations</name> <name>Key Considerations</name>
<t> <t>
HMAC keys used with this context MUST be symmetric and MUST have HMAC keys used with this context <bcp14>MUST</bcp14> be symmetric and <bcp14>MUST</bcp14> have
a key length equal to the output of the HMAC. For this reason, HMAC a key length equal to the output of the HMAC. For this reason, HMAC
key lengths will be integer divisible by 8 bytes and special padding-a ware key lengths will be integers divisible by 8 bytes, and special padding -aware
AES key wrap algorithms are not needed. AES key wrap algorithms are not needed.
</t> </t>
<t> <t>
It is assumed that any security verifier or security acceptor It is assumed that any security verifier or security acceptor
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:
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> Pre-placed keys selected based on local policy. </li> <li> Pre-placed keys selected based on local policy. </li>
<li> Keys extracted from material carried in the BIB. </li> <li> Keys extracted from material carried in the BIB. </li>
<li> Session keys negotiated via a mechanism external to the BIB. </li > <li> Session keys negotiated via a mechanism external to the BIB. </li >
</ul> </ul>
<t> <t>
When an AES-KW wrapped key is present in a security block, it is assum When an AES Key Wrap (AES-KW) <xref target="RFC3394"
ed that format="default"/> wrapped key is present in a security block, it is
security verifiers and security acceptors can independently determine assumed that security verifiers and security acceptors can
the key encryption independently determine the key encryption key (KEK) used in the
key (KEK) used in the wrapping of the symmetric HMAC key. wrapping of the symmetric HMAC key.
</t> </t>
<t> <t>
As discussed in <xref target="SecCons" format="default"/> and emphasiz ed here, it is As discussed in <xref target="SecCons" format="default"/> and emphasiz ed here, it is
strongly recommended that keys be protected once generated, both strongly recommended that keys be protected once generated, both
when they are stored and when they are transmitted. when they are stored and when they are transmitted.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Processing Considerations</name> <name>Security Processing Considerations</name>
<t> <t>
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-channe have the same value. This regularity can lead to practical
l side-channel attacks whereby an attacker could produce known
attacks whereby an attacker could produce known plain text and a plaintext, guess at an HMAC tag, and observe the behavior of a
guess at an HMAC tag and observe the behavior of a verifier. With verifier. With a modest number of trials, a side-channel attack
a modest number of trials, a side-channel attack could produce an HMAC could produce an HMAC tag for attacker-provided plaintext without
tag for attacher-provided plain text without the attacker ever knowing the attacker ever knowing the HMAC key.
the HMAC key.
</t> </t>
<t> <t>
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 way to prevent behavior analysis of this type is to ensure that
any comparisons of the supplied and expected authentication tag occur any comparisons of the supplied and expected authentication tag occur
in constant time. in constant time.
</t> </t>
<t> <t>
A constant-time comparison function SHOULD be used for the comparison A constant-time comparison function <bcp14>SHOULD</bcp14> be used for the comparison
of authentication tags by any implementation of this security context. of authentication tags by any implementation of this security context.
In cases where such a function is difficult or impossible to use, In cases where such a function is difficult or impossible to use,
the impact of side-channel (in general) and timing attacks (specifical ly) the impact of side-channel attacks (in general) and timing attacks (sp ecifically)
need to be considered as part of the implementation. need to be considered as part of the implementation.
</t> </t>
</section> </section>
<section anchor="bib_canon" numbered="true" toc="default"> <section anchor="bib_canon" numbered="true" toc="default">
<name>Canonicalization Algorithms</name> <name>Canonicalization Algorithms</name>
<t> <t>
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 construction of the IPPT depends on the settings of the
integrity scope flags that can be provided as part of customizing integrity scope flags that can be provided as part of customizing
skipping to change at line 524 skipping to change at line 523
</section> </section>
<section anchor="bib_canon" numbered="true" toc="default"> <section anchor="bib_canon" numbered="true" toc="default">
<name>Canonicalization Algorithms</name> <name>Canonicalization Algorithms</name>
<t> <t>
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 construction of the IPPT depends on the settings of the
integrity scope flags that can be provided as part of customizing integrity scope flags that can be provided as part of customizing
the behavior of this security context. the behavior of this security context.
</t> </t>
<t> <t>
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 <xref target="I-D.ietf-dtn-bpsec" fo <bcp14>MUST</bcp14> be created as described in <xref target="RFC9172"
rmat="default"/>. format="default"/>.
The canonicalization algorithms defined in <xref target="I-D.ietf-dtn- The canonicalization algorithms defined in <xref target="RFC9172" form
bpsec" format="default"/> at="default"/>
adhere to the canonical forms for extension blocks defined in adhere to the canonical forms for extension blocks defined in
<xref target="I-D.ietf-dtn-bpbis" format="default"/> but resolve ambig uities related to <xref target="RFC9171" format="default"/> but resolve ambiguities rela ted to
how values are represented in CBOR. how values are represented in CBOR.
</t> </t>
<t> <t>
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 <bcp14>MUST</bcp14> be included in the IPPT v alue itself.
</t> </t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
The canonical form of the IPPT starts as the CBOR encoding of the 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,
and unassigned bits have been set to 0. For example, if the and unassigned bits have been set to 0. For example, if the
primary block flag, target header flag, and security header flag a re primary block flag, target header flag, and security header flag a re
each set, then the initial value of the canonical form of the each set, then the initial value of the canonical form of the
IPPT will be 0x07. IPPT will be 0x07.
</li> </li>
<li> <li>
If the primary block flag of the integrity scope flags is set to 1 If the primary block flag of the integrity scope flags is set to 1 and the
, security target is not the bundle's primary block, then a canonical form of
then a canonical form of the bundle's primary block MUST be the bundle's primary block <bcp14>MUST</bcp14> be calculated and the result
calculated and the result appended to the IPPT. appended to the IPPT.
</li> </li>
<li> <li>
If the target header flag of the integrity scope flags is If the target header flag of the integrity scope flags is set to 1 and the
set to 1, then the canonical form of the block type code, security target is not the bundle's primary block, then the canonical form of
block number, and block processing control flags associated with t the block type code, block number, and block processing control flags
he associated with the security target <bcp14>MUST</bcp14> be calculated and, in
security target MUST be calculated and, in that order, that order, appended to the IPPT.
appended to the IPPT.
</li> </li>
<li> <li>
If the security header flag of the integrity scope flags is set If the security header flag of the integrity scope flags is set
to 1, then the canonical form of the block type code, to 1, then the canonical form of the block type code,
block number, and block processing control flags associated with block number, and block processing control flags associated with
the BIB MUST be calculated and, in that order, appended to the IPP T. the BIB <bcp14>MUST</bcp14> be calculated and, in that order, appe nded to the IPPT.
</li> </li>
<li> <li>
The canonical form of the security target block-type-specific The canonical form of the security target <bcp14>MUST</bcp14> be calculated
data MUST be calculated and appended to the IPPT. and 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.
</li> </li>
</ol> </ol>
<aside>
<t>NOTE: When the security target is the bundle's primary block, the
canonicalization steps associated with the primary block flag and
the target header flag are skipped. Skipping primary block flag
processing, in this case, avoids adding the bundle's primary block
twice in the IPPT calculation. Skipping target header flag
processing, in this case, is necessary because the primary block of
a bundle does not have the expected elements of a block header such
as block number and block processing control flags.
</t>
</aside>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Processing</name> <name>Processing</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Keyed Hash Generation</name> <name>Keyed Hash Generation</name>
<t> <t>
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. the appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT.
These data items MUST be generated as follows. These data items <bcp14>MUST</bcp14> be generated as follows.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
The HMAC key MUST have the appropriate length as required by The HMAC key <bcp14>MUST</bcp14> have the appropriate length
local security policy. The key can be generated specifically for as required by local security policy. The key can be
this integrity service, given as part of local security policy, generated specifically for this integrity service, given as
or through some other key management mechanism as discussed in part of local security policy, or obtained through some other
<xref target="bib_key_mgmt" format="default"/>. key management mechanism as discussed in <xref
target="bib_key_mgmt" format="default"/>.
</li> </li>
<li> <li>
Prior to the generation of the IPPT, if a CRC value is present Prior to the generation of the IPPT, if a Cyclic Redundancy Chec
for the target block of the BIB, then that CRC value MUST be k (CRC) value is present
for the target block of the BIB, then that CRC value <bcp14>MUST
</bcp14> be
removed from the target block. This involves both removing the removed from the target block. This involves both removing the
CRC value from the target block and setting the CRC Type field CRC value from the target block and setting the CRC type field
of the target block to "no CRC is present." of the target block to "no CRC is present."
</li> </li>
<li> <li>
Once CRC information is removed, the IPPT MUST be generated as Once CRC information is removed, the IPPT <bcp14>MUST</bcp14> be generated as
discussed in <xref target="bib_canon" format="default"/>. discussed in <xref target="bib_canon" format="default"/>.
</li> </li>
</ul> </ul>
<t> <t>
Upon successful hash generation the following actions MUST occur. Upon successful hash generation, the following action <bcp14>MUST</b cp14> occur.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
The keyed hash produced by the HMAC/SHA2 variant MUST be added The keyed hash produced by the HMAC/SHA2 variant <bcp14>MUST</bc p14> be added
as a security result for the BIB representing the security as a security result for the BIB representing the security
operation on this security target, as discussed operation on this security target, as discussed
in <xref target="bib_results" format="default"/>. in <xref target="bib_results" format="default"/>.
</li> </li>
</ul> </ul>
<t> <t>
Finally, the BIB containing information about this security operatio n Finally, the BIB containing information about this security operatio n
MUST be updated as follows. These operations can occur in any order. <bcp14>MUST</bcp14> be updated as follows. These operations can occu r in any order.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
The security context identifier for the BIB MUST be set to the c ontext The security context identifier for the BIB <bcp14>MUST</bcp14> be set to the context
identifier for BIB-HMAC-SHA2. identifier for BIB-HMAC-SHA2.
</li> </li>
<li> <li>
Any local flags used to generate the IPPT MUST be placed in Any local flags used to generate the IPPT <bcp14>MUST</bcp14> be
the integrity scope flags security parameter for the BIB unless placed in
the integrity scope flags security context parameter for the BIB
unless
these flags are expected to be correctly configured at security these flags are expected to be correctly configured at security
verifiers and acceptors in the network. verifiers and acceptors in the network.
</li> </li>
<li> <li>
The HMAC key MAY be included as a security parameter in which ca The HMAC key <bcp14>MAY</bcp14> be included as a security contex
se t parameter, in which case
it MUST be wrapped using the NIST AES-KW algorithm and it <bcp14>MUST</bcp14> be wrapped using the AES key wrap functio
n as defined in <xref target="RFC3394" format="default"/> and
the results of the wrapping added as the wrapped key the results of the wrapping added as the wrapped key
security parameter for the BIB. security context parameter for the BIB.
</li> </li>
<li> <li>
The SHA variant used by this security context SHOULD be added as The SHA variant used by this security context <bcp14>SHOULD</bcp
the SHA variant security parameter for the BIB if it differs fro 14> be added as
m the SHA variant security context parameter for the BIB if it dif
the default key length. Otherwise, this parameter MAY be fers from
the default key length. Otherwise, this parameter <bcp14>MAY</bc
p14> be
omitted if doing so provides a useful reduction in message sizes . omitted if doing so provides a useful reduction in message sizes .
</li> </li>
</ul> </ul>
<t> <t>
Problems encountered in the keyed hash generation MUST be Problems encountered in the keyed hash generation <bcp14>MUST</bcp14 > be
processed in accordance with local BPSec security policy. processed in accordance with local BPSec security policy.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Keyed Hash Verification</name> <name>Keyed Hash Verification</name>
<t> <t>
During keyed hash verification, the input of the security target During keyed hash verification, the input of the security target
and a HMAC key are provided to the appropriate HMAC/SHA2 algorithm. and an HMAC key are provided to the appropriate HMAC/SHA2 algorithm.
</t> </t>
<t> <t>
During keyed hash verification, two inputs are prepared for During keyed hash verification, two inputs are prepared for
the appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. the appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT.
These data items MUST be generated as follows. These data items <bcp14>MUST</bcp14> be generated as follows.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
The HMAC key MUST be derived using the wrapped key The HMAC key <bcp14>MUST</bcp14> be derived using the wrapped ke
security parameter if such a parameter is included in the y
security context parameter if such a parameter is included in th
e
security context parameters of the BIB. Otherwise, this key security context parameters of the BIB. Otherwise, this key
MUST be derived in accordance with security policy at the <bcp14>MUST</bcp14> be derived in accordance with security polic y at the
verifying node as discussed in <xref target="bib_key_mgmt" forma t="default"/>. verifying node as discussed in <xref target="bib_key_mgmt" forma t="default"/>.
</li> </li>
<li> <li>
The IPPT MUST be generated as discussed in <xref target="bib_can on" format="default"/> The IPPT <bcp14>MUST</bcp14> be generated as discussed in <xref target="bib_canon" format="default"/>
with the value of integrity scope flags being taken from the with the value of integrity scope flags being taken from the
integrity scope flags security context parameter. If the integrity scope flags security context parameter. If the
integrity scope flags parameter is not included in the integrity scope flags parameter is not included in the
security context parameters then these flags MAY be derived security context parameters, then these flags <bcp14>MAY</bcp14> be derived
from local security policy. from local security policy.
</li> </li>
</ul> </ul>
<t> <t>
The calculated HMAC output MUST be compared to the expected HMAC The calculated HMAC output <bcp14>MUST</bcp14> be compared to the ex pected 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
target. If the calculated HMAC and expected HMAC are target. If the calculated HMAC and expected HMAC are
identical, the verification MUST be considered a success. Otherwise, identical, the verification <bcp14>MUST</bcp14> be considered a succ
the verification MUST be considered a failure. ess. Otherwise,
the verification <bcp14>MUST</bcp14> be considered a failure.
</t> </t>
<t> <t>
If the verification fails or otherwise experiences an error, or if a ny If the verification fails or otherwise experiences an error or if an y
needed parameters are missing, then needed parameters are missing, then
the verification MUST be treated as failed and processed in accordan ce the verification <bcp14>MUST</bcp14> be treated as failed and proces sed in accordance
with local security policy. with local security policy.
</t> </t>
<t> <t>
This security service is removed from the bundle at the This security service is removed from the bundle at the
security acceptor as required by the BPSec specification. If the security acceptor as required by the BPSec specification <xref targe t="RFC9172" format="default"/>. If the
security acceptor is not the bundle destination and if no other security acceptor is not the bundle destination and if no other
integrity service is being applied to the target block, then a integrity service is being applied to the target block, then a
CRC MUST be included for the target block. The CRC type, as determin CRC <bcp14>MUST</bcp14> be included for the target block. The CRC ty
ed pe, 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.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default" anchor="second-context">
<name>Security Context BCB-AES-GCM</name> <name>Security Context BCB-AES-GCM</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Overview</name> <name>Overview</name>
<t> <t>
The BCB-AES-GCM security context replaces the block-type-specific data The BCB-AES-GCM security context replaces the block-type-specific data
field of its security target with cipher text generated using the field of its security target with ciphertext generated using the
Advanced Encryption Standard (AES) cipher operating in Galois/Counter Advanced Encryption Standard (AES) cipher operating in Galois/Counter
Mode (GCM) <xref target="AES-GCM" format="default"/>. The use of AES-G Mode
CM was selected (GCM) <xref target="AES-GCM" format="default"/>. The use of AES-GCM wa
s selected
as the cipher suite for this confidentiality mechanism for several rea sons: as the cipher suite for this confidentiality mechanism for several rea sons:
</t> </t>
<ol spacing="normal" type="1"><li> The selection of a symmetric-key ciph er suite allows for relatively smaller <ol spacing="normal" type="1"><li> The selection of a symmetric-key ciph er suite allows for relatively smaller
keys than asymmetric-key cipher suites. keys than asymmetric-key cipher suites.
</li> </li>
<li> The selection of a symmetric-key cipher suite allows this securit y context to <li> The selection of a symmetric-key cipher suite allows this securit y context to
be used in places where an asymmetric-key infrastructure (such as a public key be used in places where an asymmetric-key infrastructure (such as a public key
infrastructure) might be impractical. infrastructure) might be impractical.
</li> </li>
<li> <li>
The use of the Galois/Counter Mode produces cipher-text with the s The use of the Galois/Counter Mode produces ciphertext with the sa
ame size as me size as
the plain text making the replacement of target block information the plaintext making the replacement of target block information e
easier as asier as
length fields do not need to be changed. length fields do not need to be changed.
</li> </li>
<li> <li>
The AES-GCM cipher suite provides authenticated encryption, as req uired by the The AES-GCM cipher suite provides authenticated encryption, as req uired by the
BPSec protocol. BPSec protocol.
</li> </li>
</ol> </ol>
<t> <t>
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-spe authentication tag based on the plaintext value of the block-type-spec
cific ific
data and other additional authenticated data that might be specified data and other additional authenticated data (AAD) that might be speci
fied
via parameters to this security context. via parameters to this security context.
</t> </t>
<t> <t>
This security context supports two variants of AES-GCM, based on This security context supports two variants of AES-GCM, based on
the supported length of the symmetric key. These variants the supported length of the symmetric key. These variants
correspond to A128GCM and A256GCM as correspond to A128GCM and A256GCM as
defined in <xref target="RFC8152" format="default"/> Table 9: Algorith m Value for AES-GCM. defined in Table 9 ("Algorithm Value for AES-GCM") of <xref target="RF C8152" format="default"/>.
</t> </t>
<t> <t>
The BCB-AES-GCM security context MUST have the security context identi fier The BCB-AES-GCM security context <bcp14>MUST</bcp14> have the security context identifier
specified in <xref target="sc_ids" format="default"/>. specified in <xref target="sc_ids" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Scope</name> <name>Scope</name>
<t> <t>
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 confidentiality service and the scope of the authentication
service. The first defines the set of information provided to the service. The first defines the set of information provided to the
AES-GCM cipher for the purpose of producing cipher text. The second AES-GCM cipher for the purpose of producing ciphertext. The second
defines the set of information used to generate an authentication tag. defines the set of information used to generate an authentication tag.
</t> </t>
<t> <t>
The scope of the confidentiality service defines the set of informatio n The scope of the confidentiality service defines the set of informatio n
provided to the AES-GCM cipher for the purpose of producing cipher tex provided to the AES-GCM cipher for the purpose of producing ciphertext
t. .
This MUST be the full set of plain text contained in the This <bcp14>MUST</bcp14> be the full set of plaintext contained in the
block-type-specific data field of the security target. block-type-specific data field of the security target.
</t> </t>
<t> <t>
The scope of the authentication service defines the set of information The scope of the authentication service defines the set of information
used to generate an authentication tag carried with the security used to generate an authentication tag carried with the security
block. This information contains all data protected by the block. This information contains all data protected by the
confidentiality service, the scope flags used to identify other confidentiality service and the scope flags used to identify other
optional information, and MAY include other information optional information; it <bcp14>MAY</bcp14> include other information
(additional authenticated data), as follows. (additional authenticated data), as follows.
</t> </t>
<dl newline="true" spacing="normal" indent="4"> <dl newline="true" spacing="normal" indent="3">
<dt>Primary block</dt> <dt>Primary block</dt>
<dd> <dd>
<t> <t>
The primary block identifies a bundle and, once The primary block identifies a bundle, and once
created, the contents of this block are immutable. Changes to created, the contents of this block are immutable. Changes to
the primary block associated with the security target indicate the primary block associated with the security target indicate
that the security target (and BCB) might no longer be in the that the security target (and BCB) might no longer be in the
correct bundle. correct bundle.
</t> </t>
<t> <t>
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.
</t> </t>
<t> <t>
Including this information as part of additional authenticated dat a Including this information as part of additional authenticated dat a
ensures that security target (and security block) appear in the ensures that the security target (and security block) appear in th e
same bundle at the time of decryption as at the time of encryption . same bundle at the time of decryption as at the time of encryption .
</t> </t>
</dd> </dd>
<dt>Security target other fields</dt> <dt>Other fields of the security target</dt>
<dd> <dd>
<t> <t>
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 information changes how the security target is treated by nodes
in the network even when the "user data" of the security target in the network even when the "user data" of the security target
are otherwise unchanged. are otherwise unchanged.
</t> </t>
<t> <t>
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.
</t> </t>
<t> <t>
Including this information as part of additional authenticated dat a Including this information as part of additional authenticated dat a
ensures that the cipher text in the security target will not be us ed ensures that the ciphertext in the security target will not be use d
with a different set of block policy than originally set at the with a different set of block policy than originally set at the
time of encryption. time of encryption.
</t> </t>
</dd> </dd>
<dt>BCB other fields</dt> <dt>Other fields of the BCB</dt>
<dd> <dd>
<t> <t>
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 BCB processing information. Changing this information changes how the BCB
is treated by nodes in the network, even when other aspects of the is treated by nodes in the network, even when other aspects of the
BCB are unchanged. BCB are unchanged.
</t> </t>
<t> <t>
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 different at a security acceptor 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 BCB has been modified. handling the BCB has been modified.
</t> </t>
<t> <t>
Including this information as part of additional authenticated dat a Including this information as part of additional authenticated dat a
ensures that the policy and identification of the security service ensures that the policy and identification of the security service
in the bundle has not changed. in the bundle has not changed.
</t> </t>
<aside>
<t> <t>
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 additional
authenticated data because these parameters, by definition, are authenticated data because these parameters, by definition, are
those needed to verify or accept the security service. Therefore, those needed to verify or accept the security service. Therefore,
it is expected that changes to these values would result in failur es it is expected that changes to these values would result in failur es
at security verifiers and security acceptors. This is the case at security verifiers and security acceptors. This is the case
because keys cannot be re-used across security because keys cannot be reused across security
contexts, and because the AAD scope flags used to identify contexts and because the AAD scope flags used to identify
the AAD are included in the AAD. the AAD are included in the AAD.
</t> </t>
</aside>
</dd> </dd>
</dl> </dl>
<t> <t>
The scope of the BCB-AES-GCM security context is configured using The scope of the BCB-AES-GCM security context is configured using
an optional security context parameter. an optional security context parameter.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Parameters</name> <name>Parameters</name>
<t> <t>
skipping to change at line 865 skipping to change at line 887
authenticated data. authenticated data.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Initialization Vector (IV)</name> <name>Initialization Vector (IV)</name>
<t> <t>
This optional parameter identifies the initialization vector (IV) This optional parameter identifies the initialization vector (IV)
used to initialize the AES-GCM cipher. used to initialize the AES-GCM cipher.
</t> </t>
<t> <t>
The length of the initialization vector, prior to any CBOR encoding, The length of the initialization vector, prior to any CBOR encoding,
MUST be between 8-16 bytes. A value of 12 bytes SHOULD be used <bcp14>MUST</bcp14> be between 8-16 bytes. A value of 12 bytes <bcp1 4>SHOULD</bcp14> be used
unless local security policy requires a different length. unless local security policy requires a different length.
</t> </t>
<t> <t>
This value MUST be encoded as a CBOR byte string. This value <bcp14>MUST</bcp14> be encoded as a CBOR byte string.
</t> </t>
<t> <t>
The initialization vector can have any value with the caveat that a The initialization vector can have any value, with the caveat that a
value MUST NOT be re-used for multiple encryptions using the same value <bcp14>MUST NOT</bcp14> be reused for multiple encryptions usi
encryption key. This value MAY be re-used when encrypting with diffe ng the same
rent encryption key. This value <bcp14>MAY</bcp14> be reused when encrypt
ing with different
keys. For example, if each encryption operation using BCB-AES-GCM keys. For example, if each encryption operation using BCB-AES-GCM
uses a newly generated key, then the same IV can be reused. uses a newly generated key, then the same IV can be reused.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>AES Variant</name> <name>AES Variant</name>
<t> <t>
This optional parameter identifies the AES variant being used for This optional parameter identifies the AES variant being used for
the AES-GCM encryption, where the variant is identified by the lengt h the AES-GCM encryption, where the variant is identified by the lengt h
of key used. of key used.
</t> </t>
<t> <t>
This value MUST be encoded as a CBOR unsigned integer. This value <bcp14>MUST</bcp14> be encoded as a CBOR unsigned integer .
</t> </t>
<t> <t>
Valid values for this parameter are as follows. Valid values for this parameter are as follows.
</t> </t>
<t keepWithNext="true">
AES Variant Parameter Values
</t>
<table align="center"> <table align="center">
<name>AES Variant Parameter Values</name>
<thead> <thead>
<tr> <tr>
<th align="center">Value</th> <th align="center">Value</th>
<th align="center">Description</th> <th align="center">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">1</td> <td align="center">1</td>
<td align="center">A128GCM as defined in <xref target="RFC8152" format="default"/> Table 9: Algorithm Values for AES-GCM</td> <td>A128GCM as defined in Table 9 ("Algorithm Value for AES-GCM" ) of <xref target="RFC8152" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="center">3</td> <td align="center">3</td>
<td align="center">A256GCM as defined in <xref target="RFC8152" format="default"/> Table 9: Algorithm Values for AES-GCM</td> <td>A256GCM as defined in Table 9 ("Algorithm Value for AES-GCM" ) of <xref target="RFC8152" format="default"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
When not provided, implementations SHOULD assume a value of 3 When not provided, implementations <bcp14>SHOULD</bcp14> assume a va lue of 3
(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, verifie r, established by local security policy at the security source, verifie r,
or acceptor of this integrity service. or acceptor of this integrity service.
</t> </t>
<t> <t>
Regardless of the variant, the generated authentication tag MUST Regardless of the variant, the generated authentication tag <bcp14>M UST</bcp14>
always be 128 bits. always be 128 bits.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Wrapped Key</name> <name>Wrapped Key</name>
<t> <t>
This optional parameter contains the output of the AES key wrap This optional parameter contains the output of the AES key wrap funct
authenticated encryption function (KW-AE) as defined in <xref target ion as defined in <xref target="RFC3394" format="default"/>. Specifically, this
="RFC5649" format="default"/>. Specifically, parameter holds the ciphertext produced when running this key wrap algorithm wi
this parameter holds the cipher text produced when running the KW-AE th
algorithm the input string being the symmetric AES key used to generate the sec
with the input string being the symmetric AES key used to generate t urity results
he security results
present in the security block. present in the security block.
The value of this parameter is used as input to the AES key wrap aut henticated The value of this parameter is used as input to the AES key wrap aut henticated
decryption function (KW-AD) at security verifiers and security accep tors to determine decryption function at security verifiers and security acceptors to determine
the symmetric AES key needed for the proper decryption of the securi ty results the symmetric AES key needed for the proper decryption of the securi ty results
in the security block. in the security block.
</t> </t>
<t> <t>
This value MUST be encoded as a CBOR byte string. This value <bcp14>MUST</bcp14> be encoded as a CBOR byte string.
</t> </t>
<t> <t>
If this parameter is not present then security verifiers If this parameter is not present, then security verifiers
and acceptors MUST determine the proper key as a function of their l and acceptors <bcp14>MUST</bcp14> determine the proper key as a func
ocal BPSec policy tion of their local BPSec policy
and configuration. and configuration.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>AAD Scope Flags</name> <name>AAD Scope Flags</name>
<t> <t>
This optional parameter contains a series of flags that describe This optional parameter contains a series of flags that describe
what information is to be included with the what information is to be included with the
block-type-specific data of the security target as part of block-type-specific data of the security target as part of
additional authenticated data (AAD). additional authenticated data (AAD).
</t> </t>
<t> <t>
This value MUST be represented as a CBOR unsigned This value <bcp14>MUST</bcp14> be represented as a CBOR unsigned
integer, the value of which MUST be processed as a 16-bit field. integer, the value of which <bcp14>MUST</bcp14> be processed as a 16
The maximum value of this field, as a CBOR unsigned integer, MUST be -bit field.
The maximum value of this field, as a CBOR unsigned integer, <bcp14>
MUST</bcp14> be
65535. 65535.
</t> </t>
<t>When not provided, implementations <bcp14>SHOULD</bcp14> assume a va
lue 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.
</t>
<t> <t>
Implementations MUST set reserved and unassigned bits in this Implementations <bcp14>MUST</bcp14> set reserved and unassigned bits in this
field to 0 when constructing these flags at a security source. field to 0 when constructing these flags at a security source.
Once set, the value of this field MUST NOT be altered until the Once set, the value of this field <bcp14>MUST NOT</bcp14> be altered until the
security service is completed at the security acceptor in the security service is completed at the security acceptor in the
network and removed from the bundle. network and removed from the bundle.
</t> </t>
<t> <t>
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.
</t> </t>
<ul empty="true" spacing="normal">
<li>- Bit 0 (the low-order bit, 0x0001): Primary Block Flag. </li> <dl>
<li>- Bit 1 (0x0002): Target Header Flag.</li> <dt>Bit 0 (the low-order bit, 0x0001):</dt><dd>Include primary block
<li>- Bit 2 (0x0004): Security Header Flag. </li> flag</dd>
<li>- Bits 3-7 are reserved.</li> <dt>Bit 1 (0x0002):</dt><dd>Include target header flag</dd>
<li>- Bits 8-15 are unassigned.</li> <dt>Bit 2 (0x0004):</dt><dd>Include security header flag</dd>
</ul> <dt>Bits 3-7:</dt><dd>Reserved</dd>
<dt>Bits 8-15:</dt><dd>Unassigned</dd>
</dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Enumerations</name> <name>Enumerations</name>
<t> <t>
The BCB-AES-GCM security context parameters are listed in The BCB-AES-GCM security context parameters are listed in
<xref target="bcb_parm_table" format="default"/>. In this table, the "Parm Id" column <xref target="bcb_parm_table" format="default"/>. In this table, the "Parm Id" column
refers to the expected Parameter Identifier described in refers to the expected parameter identifier described in Section
<xref target="I-D.ietf-dtn-bpsec" format="default"/>, Section 3.10 <xref target="RFC9172" section="3.10" sectionFormat="bare">"Parameter
"Parameter and Result Identification"</xref> of <xref target="RFC9172"/>.
and Result Identification".
</t> </t>
<t> <t>
If the default value column is empty, this indicates that the An empty "Default Value" column indicates that the
security parameter does not have a default value. security context parameter does not have a default value.
</t>
<t keepWithNext="true">
BCB-AES-GCM Security Parameters
</t> </t>
<table align="center" anchor="bcb_parm_table"> <table align="center" anchor="bcb_parm_table">
<name>BCB-AES-GCM Security Context Parameters</name>
<thead> <thead>
<tr> <tr>
<th align="center">Parm Id</th> <th align="center">Parm Id</th>
<th align="center">Parm Name</th> <th align="center">Parm Name</th>
<th align="center">CBOR Encoding Type</th> <th align="center">CBOR Encoding Type</th>
<th align="center">Default Value</th> <th align="center">Default Value</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">1</td> <td align="center">1</td>
<td align="center">Initialization Vector</td> <td align="center">Initialization Vector</td>
<td align="center">Byte String</td> <td align="center">byte string</td>
<td align="center"/> <td align="center"/>
</tr> </tr>
<tr> <tr>
<td align="center">2</td> <td align="center">2</td>
<td align="center">AES Variant</td> <td align="center">AES Variant</td>
<td align="center">Unsigned Integer</td> <td align="center">unsigned integer</td>
<td align="center">3</td> <td align="center">3</td>
</tr> </tr>
<tr> <tr>
<td align="center">3</td> <td align="center">3</td>
<td align="center">Wrapped Key</td> <td align="center">Wrapped Key</td>
<td align="center">Byte String</td> <td align="center">byte string</td>
<td align="center"/> <td align="center"/>
</tr> </tr>
<tr> <tr>
<td align="center">4</td> <td align="center">4</td>
<td align="center">AAD Scope Flags</td> <td align="center">AAD Scope Flags</td>
<td align="center">Unsigned Integer</td> <td align="center">unsigned integer</td>
<td align="center">7</td> <td align="center">7</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="bcb_results" numbered="true" toc="default"> <section anchor="bcb_results" numbered="true" toc="default">
<name>Results</name> <name>Results</name>
<t> <t>
The BCB-AES-GCM security context produces a single security result The BCB-AES-GCM security context produces a single security result
skipping to change at line 1044 skipping to change at line 1066
<section anchor="bcb_results" numbered="true" toc="default"> <section anchor="bcb_results" numbered="true" toc="default">
<name>Results</name> <name>Results</name>
<t> <t>
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.
</t> </t>
<t> <t>
NOTES: NOTES:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
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 fiel d security result as it is stored in the block-type-specific data fiel d
of the security target block. When operating in GCM mode, AES produc es of the security target block. When operating in GCM mode, AES produc es
cipher text of the same size as its plain text and, therefore, ciphertext of the same size as its plaintext; therefore,
no additional logic is required to handle padding or overflow caused no additional logic is required to handle padding or overflow caused
by the encryption in most cases (see below). by the encryption in most cases.
</li> </li>
<li> <li>
If the authentication tag can be separated from the cipher text, the If the authentication tag can be separated from the ciphertext, then
n the tag <bcp14>MAY</bcp14> be separated and stored in the authentica
the tag MAY be separated and stored in the authentication tag tion tag
security result field. Otherwise, the security target block MUST be security result field. Otherwise, the security target block <bcp14>M
UST</bcp14> be
resized to accommodate the additional 128 bits of authentication resized to accommodate the additional 128 bits of authentication
tag included with the generated cipher text replacing the tag included with the generated ciphertext replacing the
block-type-specific-data field of the security target block. block-type-specific data field of the security target block.
</li> </li>
</ul> </ul>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Authentication Tag</name> <name>Authentication Tag</name>
<t> <t>
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 ensure any optional additional authenticated data. This tag is used to ensure
that the plain text (and important information associated with the that the plaintext (and important information associated with the
plain text) is authenticated prior to decryption. plaintext) is authenticated prior to decryption.
</t> </t>
<t> <t>
If the authentication tag is included in the cipher text placed If the authentication tag is included in the ciphertext placed
in the security target block-type-specific data field, then this in the security target block-type-specific data field, then this
security result MUST NOT be included in the BCB for that security security result <bcp14>MUST NOT</bcp14> be included in the BCB for tha t security
target. target.
</t> </t>
<t> <t>
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. <bcp14>MUST</bcp14> be 128 bits.
</t> </t>
<t> <t>
This value MUST be encoded as a CBOR byte string. This value <bcp14>MUST</bcp14> be encoded as a CBOR byte string.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Enumerations</name> <name>Enumerations</name>
<t> <t>
The BCB-AES-GCM security context results are listed in The BCB-AES-GCM security context results are listed in
<xref target="bcb_res_table" format="default"/>. In this table, the "Result Id" column <xref target="bcb_res_table" format="default"/>. In this table, the "Result Id" column
refers to the expected Result Identifier described in refers to the expected result identifier described in Section
<xref target="I-D.ietf-dtn-bpsec" format="default"/>, Section 3.10 <xref target="RFC9172" section="3.10" sectionFormat="bare">"Paramet
"Parameter er
and Result Identification". and Result Identification"</xref> of <xref target="RFC9172"/>.
</t>
<t keepWithNext="true">BCB-AES-GCM Security Results
</t> </t>
<table align="center" anchor="bcb_res_table"> <table align="center" anchor="bcb_res_table">
<name>BCB-AES-GCM Security Results</name>
<thead> <thead>
<tr> <tr>
<th align="center">Result Id</th> <th align="center">Result Id</th>
<th align="center">Result Name</th> <th align="center">Result Name</th>
<th align="center">CBOR Encoding Type</th> <th align="center">CBOR Encoding Type</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">1</td> <td align="center">1</td>
<td align="center">Authentication Tag</td> <td align="center">Authentication Tag</td>
<td align="center">Byte String</td> <td align="center">byte string</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="bcb_key_mgmt" numbered="true" toc="default"> <section anchor="bcb_key_mgmt" numbered="true" toc="default">
<name>Key Considerations</name> <name>Key Considerations</name>
<t> <t>
Keys used with this context MUST be symmetric and MUST have Keys used with this context <bcp14>MUST</bcp14> be symmetric and <bcp14> MUST</bcp14> have
a key length equal to the key length defined in the security a key length equal to the key length defined in the security
context parameters or as defined by local security policy at context parameters or as defined by local security policy at
security verifiers and acceptors. For this reason, content-encrypting security verifiers and acceptors. For this reason, content-encrypting
key lengths will be integer divisible by 8 bytes and special padding-awa re AES key lengths will be integers divisible by 8 bytes, and special padding-a ware AES
key wrap algorithms are not needed. key wrap algorithms are not needed.
</t> </t>
<t> <t>
It is assumed that any security verifier or security acceptor It is assumed that any security verifier or security acceptor
can determine the proper key to be used. Potential sources of the key can determine the proper key to be used. Potential sources of the key
include (but are not limited to) the following. include (but are not limited to) the following.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> Pre-placed keys selected based on local policy. </li> <li>Pre-placed keys selected based on local policy. </li>
<li> Keys extracted from material carried in the BCB. </li> <li>Keys extracted from material carried in the BCB. </li>
<li> Session keys negotiated via a mechanism external to the BCB. </li <li>Session keys negotiated via a mechanism external to the BCB. </li>
>
</ul> </ul>
<t> <t>
When an AES-KW wrapped key is present in a security block, it is assumed that When an AES-KW wrapped key is present in a security block, it is assumed that
security verifiers and security acceptors can independently determine th security verifiers and security acceptors can independently determine th
e key encryption e
key (KEK) used in the wrapping of the symmetric AES content-encrypting k KEK used in the wrapping of the symmetric AES content-encrypting key.
ey.
</t> </t>
<t> <t>
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 wi th processed with the same key. The total number of AES blocks processed wi th
a single key for AES-GCM is recommended to be less than 2^64, as a single key for AES-GCM is recommended to be less than 2<sup>64</sup>, as
described in Appendix B of <xref target="AES-GCM" format="default"/>. described in Appendix B of <xref target="AES-GCM" format="default"/>.
</t> </t>
<t> <t>
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 of the authenticated encryption function with a single key for
AES-GCM is required to not exceed 2^32, as described in Section AES-GCM is required to not exceed 2<sup>32</sup>, as described in Sectio n
8.3 of <xref target="AES-GCM" format="default"/>. 8.3 of <xref target="AES-GCM" format="default"/>.
</t> </t>
<t> <t>
As discussed in <xref target="SecCons" format="default"/> and emphasized here, it is As discussed in <xref target="SecCons" format="default"/> and emphasized here, it is
strongly recommended that keys be protected once generated, both strongly recommended that keys be protected once generated, both
when they are stored and when they are transmitted. when they are stored and when they are transmitted.
</t> </t>
</section> </section>
<section anchor="GcmCons" numbered="true" toc="default"> <section anchor="GcmCons" numbered="true" toc="default">
<name>GCM Considerations</name> <name>GCM Considerations</name>
<t> <t>
The GCM cryptographic mode of AES has specific requirements that The GCM cryptographic mode of AES has specific requirements that
MUST be followed by implementers for the secure function of the <bcp14>MUST</bcp14> be followed by implementers for the secure function of the
BCB-AES-GCM security context. While these requirements are well BCB-AES-GCM security context. While these requirements are well
documented in <xref target="AES-GCM" format="default"/>, some of them ar e documented in <xref target="AES-GCM" format="default"/>, some of them ar e
repeated here for emphasis. repeated here for emphasis.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
<t> <t>
With the exception of the AES-KW function, the IVs With the exception of the AES-KW function, the IVs
used by the BCB-AES-GCM security context are considered to used by the BCB-AES-GCM security context are considered to
be per-invocation IVs. be per-invocation IVs.
The pairing of a per-invocation IV and a security key The pairing of a per-invocation IV and a security key
MUST be unique. A per-invocation IV MUST NOT be used with a security <bcp14>MUST</bcp14> be unique. A per-invocation IV <bcp14>MUST NOT</
key more than one time. If a per-invocation IV and key pair are repe bcp14> be used with a security
ated then the GCM implementation key more than one time. If a per-invocation IV and key pair are repe
ated, then the GCM implementation
is vulnerable to forgery attacks. Because the loss of integrity prot ection is vulnerable to forgery attacks. Because the loss of integrity prot ection
occurs with even a single reuse, this situation is often considered to have occurs with even a single reuse, this situation is often considered to have
catastrophic security consequences. More information regarding catastrophic security consequences. More information regarding
the importance of the uniqueness of the IV value can be found in the importance of the uniqueness of the IV value can be found in
Appendix A of <xref target="AES-GCM" format="default"/>. Appendix A of <xref target="AES-GCM" format="default"/>.
</t> </t>
<t> <t>
Methods of generating unique IV values are provided in Chapter 8 Methods of generating unique IV values are provided in Section 8
of <xref target="AES-GCM" format="default"/>. For example, one metho d decomposes the of <xref target="AES-GCM" format="default"/>. For example, one metho d decomposes the
IV value into a fixed field and an invocation field. The fixed field IV value into a fixed field and an invocation field. The fixed field
being a constant value associated with a device and the invocation is a constant value associated with a device, and the invocation
field changing on each invocation (such as by incrementing an field changes on each invocation (such as by incrementing an
integer counter). Implementers SHOULD carefully read integer counter). Implementers <bcp14>SHOULD</bcp14> carefully read
all relevant sections of <xref target="AES-GCM" format="default"/> w hen generating all relevant sections of <xref target="AES-GCM" format="default"/> w hen generating
any mechanism to create unique IVs. any mechanism to create unique IVs.
</t> </t>
</li> </li>
<li> <li>
The AES-KW function used to wrap keys for the security contexts in t his document uses The AES-KW function used to wrap keys for the security contexts in t his document uses
a single, globally constant IV input to the AES cipher a single, globally constant IV input to the AES cipher
operation and, thus, is distinct from the aforementioned operation and thus is distinct from the aforementioned
requirement related to per-invocation IVs. requirement related to per-invocation IVs.
</li> </li>
<li> <li>
While any tag-based authentication mechanism has some likelihood While any tag-based authentication mechanism has some likelihood
of being forged, this probability is increased when using AES-GCM. of being forged, this probability is increased when using AES-GCM.
In particular, short tag lengths combined with very long messages In particular, short tag lengths combined with very long messages
SHOULD be avoided when using this mode. The BCB-AES-GCM security <bcp14>SHOULD</bcp14> be avoided when using this mode. The BCB-AES-G CM security
context requires the use of 128-bit authentication tags at all context requires the use of 128-bit authentication tags at all
times. Concerns relating to the size of authentication tags is times. Concerns relating to the size of authentication tags is
discussed in Appendices B and C of <xref target="AES-GCM" format="de fault"/>. discussed in Appendices B and C of <xref target="AES-GCM" format="de fault"/>.
</li> </li>
<li> <li>
As discussed in Appendix B of <xref target="AES-GCM" format="default "/>, As discussed in Appendix B of <xref target="AES-GCM" format="default "/>,
implementations SHOULD limit the number of unsuccessful implementations <bcp14>SHOULD</bcp14> limit the number of unsuccessf ul
verification attempts for each key to reduce the likelihood verification attempts for each key to reduce the likelihood
of guessing tag values. This type of check has potential of guessing tag values. This type of check has potential
state-keeping issues when AES-KW is used, since an attacker state-keeping issues when AES-KW is used, since an attacker
could cause a large number of keys to have been used at least could cause a large number of keys to be used at least
once. once.
</li> </li>
<li> <li>
As discussed in the Security Considerations section of As discussed in Section
<xref target="I-D.ietf-dtn-bpsec" format="default"/>, delay-tolerant <xref target="RFC9172" section="8" sectionFormat="bare">"Security Co
networks have a higher nsiderations"</xref> of <xref target="RFC9172"/>, delay-tolerant networks have a
higher
occurrence of replay attacks due to the store-and-forward nature occurrence of replay attacks due to the store-and-forward nature
of the network. Because GCM has no inherent replay attack of the network. Because GCM has no inherent replay attack
protection, implementors SHOULD attempt to detect replay attacks protection, implementors <bcp14>SHOULD</bcp14> attempt to detect rep lay attacks
by using mechanisms such as those described in Appendix D of by using mechanisms such as those described in Appendix D of
<xref target="AES-GCM" format="default"/>. <xref target="AES-GCM" format="default"/>.
</li> </li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Canonicalization Algorithms</name> <name>Canonicalization Algorithms</name>
<t> <t>
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.
</t> </t>
<t> <t>
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 <xref target="I-D.ietf-dtn-bpsec" form <bcp14>MUST</bcp14> be created as described in <xref target="RFC9172" fo
at="default"/>. rmat="default"/>.
The canonicalization algorithms defined in <xref target="I-D.ietf-dtn-bp The canonicalization algorithms defined in <xref target="RFC9172" format
sec" format="default"/> ="default"/>
adhere to the canonical forms for extension blocks defined in adhere to the canonical forms for extension blocks defined in
<xref target="I-D.ietf-dtn-bpbis" format="default"/> but resolve ambigui ties related to <xref target="RFC9171" format="default"/> but resolve ambiguities relate d to
how values are represented in CBOR. how values are represented in CBOR.
</t> </t>
<section anchor="bcb_canon_cipher" numbered="true" toc="default"> <section anchor="bcb_canon_cipher" numbered="true" toc="default">
<name>Cipher text related calculations</name> <name>Calculations Related to Ciphertext</name>
<t> <t>
The BCB operates over the block-type-specific data of The BCB operates over the block-type-specific data of
a block, but the BP always encodes these data within a a block, but the BP always encodes these data within a
single, definite-length CBOR byte string. Therefore, the plain text single, definite-length CBOR byte string. Therefore, the plaintext
used during encryption MUST be calculated as the value of the used during encryption <bcp14>MUST</bcp14> be calculated as the value
of the
block-type-specific data field of the security target block-type-specific data field of the security target
excluding the BP CBOR encoding. excluding the BP CBOR encoding.
</t> </t>
<t> <t>
Consider the following two CBOR encoded examples and the <xref target="enc_ex"/> shows two CBOR-encoded examples and the
plain text that would be extracted from them. The first example plaintext that would be extracted from them. The first example
is an unsigned integer, while the second is a byte string. is an unsigned integer, while the second is a byte string.
</t> </t>
<t keepWithNext="true">
CBOR Plain Text Extraction Examples
</t>
<table align="center" anchor="enc_ex"> <table align="center" anchor="enc_ex">
<name>CBOR Plaintext Extraction Examples</name>
<thead> <thead>
<tr> <tr>
<th align="center">CBOR Encoding (Hex)</th> <th align="center">CBOR Encoding (Hex)</th>
<th align="center">CBOR Part (Hex)</th> <th align="center">CBOR Part (Hex)</th>
<th align="center">Plain Text Part (Hex)</th> <th align="center">Plaintext Part (Hex)</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">18ED</td> <td align="center">18ED</td>
<td align="center">18</td> <td align="center">18</td>
<td align="center">ED</td> <td align="center">ED</td>
</tr> </tr>
<tr> <tr>
<td align="center">C24CDEADBEEFDEADBEEFDEADBEEF</td> <td align="center">C24CDEADBEEFDEADBEEFDEADBEEF</td>
skipping to change at line 1282 skipping to change at line 1304
<td align="center">18</td> <td align="center">18</td>
<td align="center">ED</td> <td align="center">ED</td>
</tr> </tr>
<tr> <tr>
<td align="center">C24CDEADBEEFDEADBEEFDEADBEEF</td> <td align="center">C24CDEADBEEFDEADBEEFDEADBEEF</td>
<td align="center">C24C</td> <td align="center">C24C</td>
<td align="center">DEADBEEFDEADBEEFDEADBEEF</td> <td align="center">DEADBEEFDEADBEEFDEADBEEF</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
Similarly, the cipher text used during decryption MUST be calculated The ciphertext used during decryption <bcp14>MUST</bcp14> be calculate d
as the single, definite-length CBOR byte string representing the as the single, definite-length CBOR byte string representing the
block-type-specific data field excluding the CBOR byte string block-type-specific data field excluding the CBOR byte string
identifying byte and optional CBOR byte string length field. identifying byte and optional CBOR byte string length field.
</t> </t>
<t> <t>
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. <bcp14>MUST NOT</bcp14> be considered as part of encryption or decrypt ion.
</t> </t>
</section> </section>
<section anchor="bcb_canon_aad" numbered="true" toc="default"> <section anchor="bcb_canon_aad" numbered="true" toc="default">
<name>Additional Authenticated Data</name> <name>Additional Authenticated Data</name>
<t> <t>
The construction of additional authenticated data depends on the The construction of additional authenticated data depends on the
AAD scope flags that can be provided as part of customizing the AAD scope flags that can be provided as part of customizing the
behavior of this security context. behavior of this security context.
</t> </t>
<t> <t>
The canonical form of the AAD input to the BCB-AES-GCM mechanism is The canonical form of the AAD input to the BCB-AES-GCM mechanism is
constructed using the following process. While the AAD scope flags constructed using the following process. While the AAD scope flags
might not be included in the BCB representing the security operation, might not be included in the BCB representing the security operation,
they MUST be included in the AAD value itself. This process MUST be they <bcp14>MUST</bcp14> be included in the AAD value itself. This pro cess <bcp14>MUST</bcp14> be
followed when generating AAD for either encryption or decryption. followed when generating AAD for either encryption or decryption.
</t> </t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
The canonical form of the AAD starts as the CBOR encoding The canonical form of the AAD starts as the CBOR encoding
of the AAD scope flags in which all unset flags, reserved bits, of the AAD scope flags in which all unset flags, reserved bits,
and unassigned bits have been set to 0. For example, if the and unassigned bits have been set to 0. For example, if the
primary block flag, target header flag, and security header flag a re primary block flag, target header flag, and security header flag a re
each set, then the initial value of the canonical form of the each set, then the initial value of the canonical form of the
AAD will be 0x07. AAD will be 0x07.
</li> </li>
<li> <li>
If the primary block flag of the AAD scope flags is set to If the primary block flag of the AAD scope flags is set to
1, then a canonical form of the bundle's primary 1, then a canonical form of the bundle's primary
block MUST be calculated and the result appended to the AAD. block <bcp14>MUST</bcp14> be calculated and the result appended to the AAD.
</li> </li>
<li> <li>
If the target header flag of the AAD scope flags is set to If the target header flag of the AAD scope flags is set to
1, then the canonical form of the block type code, 1, then the canonical form of the block type code,
block number, and block processing control flags associated with t he block number, and block processing control flags associated with t he
security target MUST be calculated and, in that order, appended security target <bcp14>MUST</bcp14> be calculated and, in that ord er, appended
to the AAD. to the AAD.
</li> </li>
<li> <li>
If the security header flag of the AAD scope flags is set to 1, If the security header flag of the AAD scope flags is set to 1,
then the canonical form of the block type code, then the canonical form of the block type code,
block number, and block processing control flags associated with block number, and block processing control flags associated with
the BIB MUST be calculated and, in that order, appended to the AAD . the BIB <bcp14>MUST</bcp14> be calculated and, in that order, appe nded to the AAD.
</li> </li>
</ol> </ol>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Processing</name> <name>Processing</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Encryption</name> <name>Encryption</name>
<t> <t>
During encryption, four inputs are prepared for input to the During encryption, four data elements are prepared for input to the
AES/GCM cipher: the encryption key, the IV, AES-GCM cipher: the encryption key, the IV,
the security target plain text to be encrypted, and any the security target plaintext to be encrypted, and any
additional authenticated data. These data items MUST be generated additional authenticated data. These data items <bcp14>MUST</bcp14> be
generated
as follows. as follows.
</t> </t>
<t> <t>
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 <bcp14>MUST</bcp14> be removed. This requires remo ving 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."
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
The encryption key MUST have the appropriate length as required by The encryption key <bcp14>MUST</bcp14> have the appropriate
local security policy. The key might be generated specifically for length as required by local security policy. The key might be
this generated specifically for this encryption, given as part of
encryption, given as part of local security policy, or through som local security policy, or obtained through some other key
e management mechanism as discussed in <xref target="bcb_key_mgmt"
other key management mechanism as discussed in format="default"/>.
<xref target="bcb_key_mgmt" format="default"/>.
</li> </li>
<li> <li>
The IV selected MUST be of the appropriate The IV selected <bcp14>MUST</bcp14> be of the appropriate
length. Because replaying an IV in counter mode voids the length. Because replaying an IV in counter mode voids the
confidentiality of all messages encrypted with said IV, this confidentiality of all messages encrypted with said IV, this
context also requires a unique IV for every encryption performed context also requires a unique IV for every encryption performed
with the same key. This means the same key and IV combination MUST with the same key. This means the same key and IV combination <bcp
NOT be used more than once. 14>MUST
NOT</bcp14> be used more than once.
</li> </li>
<li> <li>
The security target plain text for encryption MUST be generated as The security target plaintext for encryption <bcp14>MUST</bcp14> b e generated as
discussed in <xref target="bcb_canon_cipher" format="default"/>. discussed in <xref target="bcb_canon_cipher" format="default"/>.
</li> </li>
<li> <li>
Additional authenticated data MUST be generated as Additional authenticated data <bcp14>MUST</bcp14> be generated as
discussed in <xref target="bcb_canon_aad" format="default"/> with discussed in <xref target="bcb_canon_aad" format="default"/>, with
the value of the value of
AAD scope flags being taken from local security policy. AAD scope flags being taken from local security policy.
</li> </li>
</ul> </ul>
<t> <t>
Upon successful encryption the following actions MUST occur. Upon successful encryption, the following actions <bcp14>MUST</bcp14> occur.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
The cipher text produced by AES/GCM MUST replace the bytes used The ciphertext produced by AES-GCM <bcp14>MUST</bcp14> replace the
to define the plain text in the security target block's bytes used
to define the plaintext in the security target block's
block-type-specific data field. The block length of the security block-type-specific data field. The block length of the security
target MUST be updated if the generated cipher text is larger target <bcp14>MUST</bcp14> be updated if the generated ciphertext
than the plain text (which can occur when the authentication is larger
tag is included in the cipher text calculation, as discussed than the plaintext (which can occur when the authentication
tag is included in the ciphertext calculation, as discussed
in <xref target="bcb_results" format="default"/>). in <xref target="bcb_results" format="default"/>).
</li> </li>
<li> <li>
The authentication tag calculated by the AES/GCM cipher MAY be The authentication tag calculated by the AES-GCM cipher <bcp14>MAY </bcp14> 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 holding results for this security operation, in which case it
MUST be processed as described in <xref target="bcb_results" forma t="default"/>. <bcp14>MUST</bcp14> be processed as described in <xref target="bcb _results" format="default"/>.
</li> </li>
<li> <li>
The authentication tag MUST be included either as a security The authentication tag <bcp14>MUST</bcp14> be included either as a security
result in the BCB representing the security operation or result in the BCB representing the security operation or
(with the cipher text) in the security target block-type-specific (with the ciphertext) in the security target block-type-specific
data field. data field.
</li> </li>
</ul> </ul>
<t> <t>
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. <bcp14>MUST</bcp14> be updated as follows. These operations can occur in any order.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
The security context identifier for the BCB MUST be set to the con text The security context identifier for the BCB <bcp14>MUST</bcp14> be set to the context
identifier for BCB-AES-GCM. identifier for BCB-AES-GCM.
</li> </li>
<li> <li>
The IV input to the cipher MUST be added as the IV security The IV input to the cipher <bcp14>MUST</bcp14> be added as the
parameter for the BCB. IV security context parameter for the BCB.
</li> </li>
<li> <li>
Any local flags used to generated AAD for this cipher MUST be Any local flags used to generate AAD for this cipher <bcp14>MUST</
placed in the AAD scope flags security parameter for the BCB bcp14> be
placed in the AAD scope flags security context parameter for the B
CB
unless these flags are expected to be correctly configured at 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.
</li> </li>
<li> <li>
The encryption key MAY be included as a security parameter in whic The encryption key <bcp14>MAY</bcp14> be included as a security
h context parameter, in which case it <bcp14>MUST</bcp14> be
case it MUST be wrapped using the NIST AES-KW algorithm and wrapped using the AES key wrap function as defined in <xref
the results of the wrapping added as the wrapped key target="RFC3394" format="default"/> and the results of the
security parameter for the BCB. wrapping added as the wrapped key security context parameter for
the BCB.
</li> </li>
<li> <li>
The AES variant used by this security context SHOULD be added as The AES variant used by this security context <bcp14>SHOULD</bcp14
the AES variant security parameter for the BCB if it differs from > be added as
the default key length. Otherwise, this parameter MAY be the AES variant security context parameter for the BCB if it diffe
rs from
the default key length. Otherwise, this parameter <bcp14>MAY</bcp1
4> be
omitted if doing so provides a useful reduction in message sizes. omitted if doing so provides a useful reduction in message sizes.
</li> </li>
</ul> </ul>
<t> <t>
Problems encountered in the encryption MUST be processed in accordanc Problems encountered in the encryption <bcp14>MUST</bcp14> be process
e ed in accordance
with local security policy. This MAY include restoring a CRC value with local security policy. This <bcp14>MAY</bcp14> include restoring
a CRC value
removed from the target block prior to encryption, if the target bloc k removed from the target block prior to encryption, if the target bloc k
is allowed to be transmitted after an encryption error. is allowed to be transmitted after an encryption error.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Decryption</name> <name>Decryption</name>
<t> <t>
During decryption, five inputs are prepared for input to the During decryption, five data elements are prepared for input to the
AES/GCM cipher: the decryption key, the IV, AES-GCM cipher: the decryption key, the IV,
the security target cipher text to be decrypted, any additional the security target ciphertext to be decrypted, any additional
authenticated data, and the authentication tag generated from the authenticated data, and the authentication tag generated from the
original encryption. These data items MUST be generated as follows. original encryption. These data items <bcp14>MUST</bcp14> be generated as follows.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
The decryption key MUST be derived using the wrapped key The decryption key <bcp14>MUST</bcp14> be derived using the wrappe
security parameter if such a parameter is included in the d key
security context parameters of the BCB. Otherwise this key security context parameter if such a parameter is included in the
MUST be derived in accordance with local security policy at the security context parameters of the BCB. Otherwise, this key
<bcp14>MUST</bcp14> be derived in accordance with local security p
olicy at the
decrypting node as discussed in <xref target="bcb_key_mgmt" format ="default"/>. decrypting node as discussed in <xref target="bcb_key_mgmt" format ="default"/>.
</li> </li>
<li> <li>
The IV MUST be set to the value of the The IV <bcp14>MUST</bcp14> be set to the value of the
IV security parameter included in the BCB. If the IV parameter IV security context parameter included in the BCB. If the IV param
is not included as a security parameter, an IV MAY be derived eter
as a function of local security policy and other BCB contents or is not included as a security context parameter, an IV <bcp14>MAY<
a lack of an IV security parameter in the BCB MAY be treated /bcp14> be derived
as a function of local security policy and other BCB contents, or
a lack of an IV security context parameter in the BCB <bcp14>MAY</
bcp14> be treated
as an error by the decrypting node. as an error by the decrypting node.
</li> </li>
<li> <li>
The security target cipher text for decryption MUST be generated a s The security target ciphertext for decryption <bcp14>MUST</bcp14> be generated as
discussed in <xref target="bcb_canon_cipher" format="default"/>. discussed in <xref target="bcb_canon_cipher" format="default"/>.
</li> </li>
<li> <li>
Additional authenticated data MUST be generated as Additional authenticated data <bcp14>MUST</bcp14> be generated as
discussed in <xref target="bcb_canon_aad" format="default"/> with the value of discussed in <xref target="bcb_canon_aad" format="default"/> with the value of
AAD scope flags being taken from the AAD scope flags AAD scope flags being taken from the AAD scope flags
security context parameter. If the AAD scope flags parameter is security context parameter. If the AAD scope flags parameter is
not included in the security context parameters then these flags not included in the security context parameters, then these flags
MAY be derived from local security policy in cases where the <bcp14>MAY</bcp14> be derived from local security policy in cases
where the
set of such flags is determinable in the network. set of such flags is determinable in the network.
</li> </li>
<li> <li>
The authentication tag MUST be present either as a security The authentication tag <bcp14>MUST</bcp14> be present either as a security
result in the BCB representing the security operation or result in the BCB representing the security operation or
(with the cipher text) in the security target block-type-specific (with the ciphertext) in the security target block-type-specific
data field. data field.
</li> </li>
</ul> </ul>
<t> <t>
Upon successful decryption the following actions MUST occur. Upon successful decryption, the following action <bcp14>MUST</bcp14> o ccur.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
The plain text produced by AES/GCM MUST replace the bytes used The plaintext produced by AES-GCM <bcp14>MUST</bcp14> replace
to define the cipher text in the security target block's the bytes used to define the ciphertext in the security target
block-type-specific data field. Any changes to the security target block's block-type-specific data field. Any changes to the
block length field MUST be corrected in cases where the plain security target block length field <bcp14>MUST</bcp14> be
text has a different length than the replaced cipher text. corrected in cases where the plaintext has a different length
than the replaced ciphertext.
</li> </li>
</ul> </ul>
<t> <t>
If the security acceptor is not the bundle destination and if no other If the security acceptor is not the bundle destination and if no other
integrity or confidentiality service is being applied to the target bl ock, integrity or confidentiality service is being applied to the target bl ock,
then a CRC MUST be included for the target block. The CRC type, as det ermined then a CRC <bcp14>MUST</bcp14> be included for the target block. The C RC 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.
</t> </t>
<t> <t>
If the cipher text fails to authenticate, if any needed parameters If the ciphertext fails to authenticate, if any needed parameters
are missing, or if there are other problems in the decryption then are missing, or if there are other problems in the decryption, then
the decryption MUST be treated as failed and processed in accordance the decryption <bcp14>MUST</bcp14> be treated as failed and processed
in accordance
with local security policy. with local security policy.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA" toc="default" numbered="true"> <section anchor="IANA" toc="default" numbered="true">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="sc_ids" numbered="true" toc="default"> <section anchor="sc_ids" numbered="true" toc="default">
<name>Security Context Identifiers</name> <name>Security Context Identifiers</name>
<t> <t>
This specification allocates two security context identifiers from the This specification allocates two security context identifiers from the
"BPSec Security Context Identifiers" registry defined in "BPSec Security Context Identifiers" registry defined in
<xref target="I-D.ietf-dtn-bpsec" format="default"/>. <xref target="RFC9172" format="default"/>.
</t> </t>
<t keepWithNext="true">Additional Entries for the BPSec Security Context Identifiers Registry:</t>
<table align="center" anchor="iana_table"> <table align="center" anchor="iana_table">
<name>Additional Entries for the BPSec Security Context Identifiers Regi stry</name>
<thead> <thead>
<tr> <tr>
<th align="center">Value</th> <th align="center">Value</th>
<th align="center">Description</th> <th>Description</th>
<th align="center">Reference</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">TBA</td> <td align="center">1</td>
<td align="center">BIB-HMAC-SHA2</td> <td>BIB-HMAC-SHA2</td>
<td align="center">This document</td> <td>RFC 9173</td>
</tr> </tr>
<tr> <tr>
<td align="center">TBA</td> <td align="center">2</td>
<td align="center">BCB-AES-GCM</td> <td>BCB-AES-GCM</td>
<td align="center">This document</td> <td>RFC 9173</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Integrity Scope Flags</name> <name>Integrity Scope Flags</name>
<t> <t>
The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field for The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field for
which IANA is requested to create and maintain a new registry named which IANA has created and now maintains a new registry named
"BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the Bundle Protocol reg "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the "Bundle Protocol" r
istry page. egistry page.
Initial values for this registry are given below. <xref target="bib_flags"/> shows the initial values for this registry.
</t> </t>
<t> <t>
The registration policy for this registry is: Specification Required. The registration policy for this registry is Specification Required <x ref target="RFC8126"/>.
</t> </t>
<t> <t>
The value range is unsigned 16-bit integer. The value range is unsigned 16-bit integer.
</t> </t>
<t keepWithNext="true">
BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry
</t>
<table align="center" anchor="bib_flags"> <table align="center" anchor="bib_flags">
<name>BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center">Bit Position (right to left)</th> <th align="center">Bit Position (right to left)</th>
<th align="center">Description</th> <th>Description</th>
<th align="center">Reference</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">0</td> <td align="center">0</td>
<td align="center">Include primary block</td> <td>Include primary block flag</td>
<td align="center">This document</td> <td>RFC 9173</td>
</tr> </tr>
<tr> <tr>
<td align="center">1</td> <td align="center">1</td>
<td align="center">Include target header flag</td> <td>Include target header flag</td>
<td align="center">This document</td> <td>RFC 9173</td>
</tr> </tr>
<tr> <tr>
<td align="center">2</td> <td align="center">2</td>
<td align="center">Include security header flag</td> <td>Include security header flag</td>
<td align="center">This document</td> <td>RFC 9173</td>
</tr> </tr>
<tr> <tr>
<td align="center">3-7</td> <td align="center">3-7</td>
<td align="center">reserved</td> <td>Reserved</td>
<td align="center">This document</td> <td>RFC 9173</td>
</tr> </tr>
<tr> <tr>
<td align="center">8-15</td> <td align="center">8-15</td>
<td align="center">unassigned</td> <td>Unassigned</td>
<td align="center">This document</td> <td></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>AAD Scope Flags</name> <name>AAD Scope Flags</name>
<t> <t>
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 is requested to create and maintain a new registry named which IANA has created and now maintains a new registry named
"BPSec BCB-AES-GCM AAD Scope Flags" on the Bundle Protocol registry pa "BPSec BCB-AES-GCM AAD Scope Flags" on the "Bundle Protocol" registry
ge. page.
Initial values for this registry <xref target="bcb_flags"/> shows the initial values for this registry.
are given below.
</t> </t>
<t> <t>
The registration policy for this registry is: Specification Required. The registration policy for this registry is Specification Required.
</t> </t>
<t> <t>
The value range is unsigned 16-bit integer. The value range is unsigned 16-bit integer.
</t> </t>
<t keepWithNext="true">
BPSec BCB-AES-GCM AAD Scope Flags Registry
</t>
<table align="center" anchor="bcb_flags"> <table align="center" anchor="bcb_flags">
<name>BPSec BCB-AES-GCM AAD Scope Flags Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center">Bit Position (right to left)</th> <th align="center">Bit Position (right to left)</th>
<th align="center">Description</th> <th>Description</th>
<th align="center">Reference</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">0</td> <td align="center">0</td>
<td align="center">Include primary block</td> <td>Include primary block flag</td>
<td align="center">This document</td> <td>RFC 9173</td>
</tr> </tr>
<tr> <tr>
<td align="center">1</td> <td align="center">1</td>
<td align="center">Include target header flag</td> <td>Include target header flag</td>
<td align="center">This document</td> <td>RFC 9173</td>
</tr> </tr>
<tr> <tr>
<td align="center">2</td> <td align="center">2</td>
<td align="center">Include security header flag</td> <td>Include security header flag</td>
<td align="center">This document</td> <td>RFC 9173</td>
</tr> </tr>
<tr> <tr>
<td align="center">3-7</td> <td align="center">3-7</td>
<td align="center">reserved</td> <td>Reserved</td>
<td align="center">This document</td> <td>RFC 9173</td>
</tr> </tr>
<tr> <tr>
<td align="center">8-15</td> <td align="center">8-15</td>
<td align="center">unassigned</td> <td>Unassigned</td>
<td align="center">This document</td> <td></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Guidance for Designated Experts</name> <name>Guidance for Designated Experts</name>
<t> <t>
New assignments within the BIB-HMAC-SHA2 New assignments within the "BPSec BIB-HMAC-SHA2
Integrity Scope Flags Registry and the Integrity Scope Flags" and
BCB-AES-GCM AAD Scope Flags Registry require "BPSec BCB-AES-GCM AAD Scope Flags" registries require
review by a Designated Expert (DE). This section review by a Designated Expert (DE). This section
provides guidance to the DE when performing their provides guidance to the DE when performing their
reviews. Specifically, a DE is expected to perform reviews. Specifically, a DE is expected to perform
the following activities. the following activities.
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
Ascertain the existence of suitable documentation Ascertain the existence of suitable documentation
(a specification) as described in <xref target="RFC8126" format= "default"/> (a specification) as described in <xref target="RFC8126" format= "default"/>
and to verify that the document is permanently and and verify that the document is permanently and
publicly available. publicly available.
</li> </li>
<li> <li>
Ensure that any changes to the Integrity Scope Flags Ensure that any changes to the "BPSec BIB-HMAC-SHA2 Integrity Sc ope Flags" registry
clearly state how new assignments interact with existing clearly state how new assignments interact with existing
flags and how the inclusion of new assignments affects flags and how the inclusion of new assignments affects
the construction of the IPPT value. the construction of the IPPT value.
</li> </li>
<li> <li>
Ensure that any changes to the AAD Scope Flags clearly Ensure that any changes to the "BPSec BCB-AES-GCM AAD Scope Flag s" registry clearly
state how new assignments interact with existing state how new assignments interact with existing
flags and how the inclusion of new assignments affects flags and how the inclusion of new assignments affects
the construction of the AAD input to the BCB-AES-GCM mechanism. the construction of the AAD input to the BCB-AES-GCM mechanism.
</li> </li>
<li> <li>
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.
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="SecCons" numbered="true" toc="default"> <section anchor="SecCons" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
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. This section discusses provided in the description of that context (see Sections <xref target="fi rst-context" format="counter"/> and <xref target="second-context" format="counte r"/>). This section discusses
security considerations that should be evaluated by implementers of any security considerations that should be evaluated by implementers of any
security context described in this document. Considerations can also be security context described in this document. Considerations can also be
found in documents listed as normative references and they should also be found in documents listed as normative references and should also be
reviewed by security context implementors. reviewed by security context implementors.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Key Management</name> <name>Key Management</name>
<t> <t>
The delayed and disrupted nature of DTNs complicates the process of key The delayed and disrupted nature of Delay-Tolerant
management Networking (DTN) complicates the process of key management
because there might not be reliable, timely round-trip exchange between because there might not be reliable, timely, round-trip exchange between
security security
sources, security verifiers, and security acceptors in the network. This is true when sources, security verifiers, and security acceptors in the network. This is true when
there is a substantial signal propagation delay between nodes, when node s are in a highly there is a substantial signal propagation delay between nodes, when node s are in a highly
challenged communications environment, and when nodes do not support bi- directional challenged communications environment, and when nodes do not support bid irectional
communication. communication.
</t> </t>
<t> <t>
In these environments, key establishment protocols that rely on round-tr ip information In these environments, key establishment protocols that rely on round-tr ip information
exchange might not converge on a shared secret in a timely manner (or at all). Also, exchange might not converge on a shared secret in a timely manner (or at all). Also,
key revocation or key verification mechanisms that rely on access to a c entralized key revocation or key verification mechanisms that rely on access to a c entralized
authority (such as a certificate authority) might similarly fail in the stressing authority (such as a certificate authority) might similarly fail in the stressing
conditions of a DTN. conditions of DTN.
</t> </t>
<t> <t>
For these reasons, the default security contexts described in this docum ent rely For these reasons, the default security contexts described in this docum ent rely
on symmetric key cryptographic mechanisms because asymmetric key infrast ructure (such on symmetric-key cryptographic mechanisms because asymmetric-key infrast ructure (such
as a public key infrastructure) might be impractical in this environment . as a public key infrastructure) might be impractical in this environment .
</t> </t>
<t> <t>
BPSec assumes that "key management is handled as a separate part of netw ork management" BPSec assumes that "key management is handled as a separate part of netw ork management"
<xref target="I-D.ietf-dtn-bpsec" format="default"/>. This assumption is <xref target="RFC9172" format="default"/>. This assumption is also made
also made by the security contexts defined in this document, which do not define n
by the security contexts defined in this document which do not define ne ew protocols for
w protocols for key derivation, exchange of KEKs, revocation of existing keys,
key derivation, exchange of key-encrypting keys, revocation of existing
keys,
or the security configuration or policy used to select certain keys for certain or the security configuration or policy used to select certain keys for certain
security operations. security operations.
</t> </t>
<t> <t>
Nodes using these security contexts need to perform the following kinds of Nodes using these security contexts need to perform the following kinds of
activities, independent of the construction, transmission, and processin g of activities, independent of the construction, transmission, and processin g of
BPSec security blocks. BPSec security blocks.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
Establish shared key-encrypting-keys with other nodes in the network Establish shared KEKs with other nodes in the network using
using an out-of-band mechanism. This might include pre-sharing of KEKs
an out-of-band mechanism. This might include pre-sharing of key encr or the use of older key establishment mechanisms prior to the
yption exchange of BPSec security blocks.
keys or the use of traditional key establishment mechanisms prior to
the
exchange of BPsec security blocks.
</li> </li>
<li> <li>
Determine when a key is considered exhausted and no longer to be use d in Determine when a key is considered exhausted and no longer to be use d in
the generation, verification, or acceptance of a security block. the generation, verification, or acceptance of a security block.
</li> </li>
<li> <li>
Determine when a key is considered invalid and no longer to be used in the Determine when a key is considered invalid and no longer to be used in the
generation, verification, or acceptance of a security block. Such re vocations generation, verification, or acceptance of a security block. Such re vocations
can be based on a variety of mechanisms to include local security po can be based on a variety of mechanisms, including local security po
licy, licy,
time relative to the generation or use of the key, or as time relative to the generation or use of the key, or other mechanis
ms
specified through network management. specified through network management.
</li> </li>
<li> <li>
Determine, through an out-of-band mechanism such as local security p olicy, Determine, through an out-of-band mechanism such as local security p olicy,
what keys are to be used for what security blocks. This includes the selection what keys are to be used for what security blocks. This includes the selection
of which key should be used in the evaluation of a security block re ceived by of which key should be used in the evaluation of a security block re ceived by
a security verifier or a security acceptor. a security verifier or a security acceptor.
</li> </li>
</ul> </ul>
<t> <t>
skipping to change at line 1783 skipping to change at line 1810
for the operational networking environment can result in the compromise of for the operational networking environment can result in the compromise of
those unmanaged keys and the loss of security services in the network. those unmanaged keys and the loss of security services in the network.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Key Handling</name> <name>Key Handling</name>
<t> <t>
Once generated, keys should be handled as follows. Once generated, keys should be handled as follows.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
It is strongly RECOMMENDED that implementations protect keys both It is strongly <bcp14>RECOMMENDED</bcp14> that implementations prote ct keys both
when they are stored and when they are transmitted. when they are stored and when they are transmitted.
</li> </li>
<li> <li>
In the event that a key is compromised, any security operations usin g In the event that a key is compromised, any security operations usin g
a security context associated with that key SHOULD also be a security context associated with that key <bcp14>SHOULD</bcp14> al so be
considered compromised. This means that the BIB-HMAC-SHA2 security c ontext considered compromised. This means that the BIB-HMAC-SHA2 security c ontext
SHOULD NOT be treated as providing integrity when used with a compro <bcp14>SHOULD NOT</bcp14> be treated as providing integrity when use
mised key and d with a compromised key, and
BCB-AES-GCM SHOULD NOT be treated as providing confidentiality when BCB-AES-GCM <bcp14>SHOULD NOT</bcp14> be treated as providing confid
used with a compromised key. entiality when used with a compromised key.
</li> </li>
<li> <li>
The same key, whether a key-encrypting-key or a wrapped key, MUST NO T The same key, whether a KEK or a wrapped key, <bcp14>MUST NOT</bcp14 >
be used for different algorithms as doing so might leak information be used for different algorithms as doing so might leak information
about the key. about the key.
</li> </li>
<li> <li>
A key-encrypting-key MUST NOT be used to encrypt keys for different A KEK <bcp14>MUST NOT</bcp14> be used to encrypt keys for different
security security
contexts. Any key-encrypting-key used by a security context defined contexts. Any KEK used by a security context defined in this documen
in this document MUST t <bcp14>MUST</bcp14>
only be used to wrap keys associated with security operations using only be used to wrap keys associated with security operations using
that security context. This means that a compliant security source that security context. This means that a compliant security source
would not use the same key-encrypting-key to wrap keys for both the BIB-HMAC-SHA2 and would not use the same KEK to wrap keys for both the BIB-HMAC-SHA2 a nd
BCB-AES-GCM security contexts. Similarly, any compliant security ver ifier BCB-AES-GCM security contexts. Similarly, any compliant security ver ifier
or security acceptor would not use the same key-encrypting-key to un wrap keys or security acceptor would not use the same KEK to unwrap keys
for different security contexts. for different security contexts.
</li> </li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>AES GCM</name> <name>AES GCM</name>
<t> <t>
There are a significant number of considerations related to the use of t he There are a significant number of considerations related to the use of t he
GCM mode of AES to provide a confidentiality service. These consideratio ns GCM mode of AES to provide a confidentiality service. These consideratio ns
are provided in <xref target="GcmCons" format="default"/> as part of the documentation are provided in <xref target="GcmCons" format="default"/> as part of the documentation
of the BCB-AES-GCM security context. of the BCB-AES-GCM security context.
</t> </t>
<t> <t>
The length of the cipher text produced by the The length of the ciphertext produced by the
GCM mode of AES will be equal to the length of the plain text input GCM mode of AES will be equal to the length of the plaintext input
to the cipher suite. The authentication tag also produced by this to the cipher suite. The authentication tag also produced by this
cipher suite is separate from the cipher text. However, it should be cipher suite is separate from the ciphertext. However, it should be
noted that implementations of the AES-GCM cipher suite might not separat e noted that implementations of the AES-GCM cipher suite might not separat e
the concept of cipher text and authentication tag in their application the concept of ciphertext and authentication tag in their Application
programming interface (API). Programming Interface (API).
</t> </t>
<t> <t>
Implementations of the BCB-AES-GCM security context can either keep the length Implementations of the BCB-AES-GCM security context can either keep the length
of the target block unchanged by holding the authentication tag in a BCB of the target block unchanged by holding the authentication tag in a BCB
security result or alter the length of the target block by including the security result or alter the length of the target block by including the
authentication tag with the cipher text replacing the block-type-specifi authentication tag with the ciphertext replacing the block-type-specific
c-data data
field of the target block. Implementations MAY use the authentication ta field of the target block. Implementations <bcp14>MAY</bcp14> use the au
g thentication tag
security result in cases where keeping target block length unchanged is an security result in cases where keeping target block length unchanged is an
important processing concern. In all cases, the cipher text and authenti important processing concern. In all cases, the ciphertext and authentic
cation ation
tag MUST be processed in accordance with the API of the AES-GCM cipher s tag <bcp14>MUST</bcp14> be processed in accordance with the API of the A
uites ES-GCM cipher suites
at the security source and security acceptor. at the security source and security acceptor.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>AES Key Wrap</name> <name>AES Key Wrap</name>
<t> <t>
The AES key wrap (AES-KW) algorithm used by the security contexts in thi s document The AES-KW algorithm used by the security contexts in this document
does not use a per-invocation initialization vector and does not require any key padding. Key padding is does not use a per-invocation initialization vector and does not require any key padding. Key padding is
not needed because wrapped keys used by these security contexts will alw ays be multiples of 8 not needed because wrapped keys used by these security contexts will alw ays be multiples of 8
bytes. The length of the wrapped key can be determined by inspecting the security bytes. The length of the wrapped key can be determined by inspecting the security
context parameters. Therefore, a key can be unwrapped using only the inf ormation present context parameters. Therefore, a key can be unwrapped using only the inf ormation present
in the security block and the key encryption key provided by local secur ity policy at the security verifier in the security block and the KEK provided by local security policy at t he security verifier
or security acceptor. or security acceptor.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle Fragmentation</name> <name>Bundle Fragmentation</name>
<t> <t>
Bundle fragmentation might prevent security services in a bundle from be ing Bundle fragmentation might prevent security services in a bundle from be ing
verified after a bundle is fragmented and before the bundle is 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.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
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 the same fragment, then the security block cannot be processed until the
bundle is re-assembled. If a fragment includes an encrypted bundle is re-assembled. If a fragment includes an encrypted
target block, but not its BCB, then a receiving bundle processing target block, but not its BCB, then a receiving Bundle Protocol
agent (BPA) will not know that the target block has been encrypted. Agent (BPA) will not know that the target block has been encrypted.
</li> </li>
<li> <li>
A security block can be cryptographically bound to a bundle by setti ng the A security block can be cryptographically bound to a bundle by setti ng the
Integrity Scope Flags (for BIB-HMAC-SHA2) or the AAD Scope Flags (fo r integrity scope flags (for BIB-HMAC-SHA2) or the AAD scope flags (fo r
BCB-AES-GCM) to include the bundle primary block. When a security BCB-AES-GCM) to include the bundle primary block. When a security
block is cryptographically bound to a bundle, it cannot be processed block is cryptographically bound to a bundle, it cannot be processed
even if the security block and target both coexist in the fragment. This even if the security block and target both coexist in the fragment. This
is because fragments have different primary blocks than the original bundle. is because fragments have different primary blocks than the original bundle.
</li> </li>
<li> <li>
If security blocks and their target blocks are repeated in If security blocks and their target blocks are repeated in
multiple fragments, policy needs to determine how to deal with issue s multiple fragments, policy needs to determine how to deal with issue s
where a security operation verifies in one fragment but fails where a security operation verifies in one fragment but fails
in another fragment. This might happen, for example, if a BIB block in another fragment. This might happen, for example, if a BIB block
skipping to change at line 1905 skipping to change at line 1933
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .8152.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .8152.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .8949.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .8949.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .8742.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .8742.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3394.xml"/>
<reference anchor="AES-GCM"> <reference anchor="AES-GCM">
<front> <front>
<title>NIST Special Publication 800-38D: <title>Recommendation for Block Cipher Modes of Operation:
Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title>
Galois/Counter Mode (GCM) and GMAC.</title>
<author initials="M." surname="Dworkin"/> <author initials="M." surname="Dworkin"/>
<date year="2007" month="November"/> <date year="2007" month="November"/>
</front> </front>
<seriesInfo name='NIST Special Publication' value='800-38D' />
<seriesInfo name='DOI' value='10.6028/NIST.SP.800-38D' />
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5649.xml"/> <reference anchor="SHS" target="https://csrc.nist.gov/publications/detail/
<reference anchor="SHS"> fips/180/4/final">
<front> <front>
<title>Secure Hash Standard (SHS).</title> <title>Secure Hash Standard (SHS)</title>
<author> <author>
<organization>US NIST</organization> <organization>National Institute of Standards and Technology</organi zation>
</author> </author>
<date year="2015" month="August"/> <date year="2015" month="August"/>
</front> </front>
<!-- This is an abuse of this field, but I could not get the <seriesInfo name="FIPS PUB" value="180-4"/>
rendering order I wanted otherwise. --> <seriesInfo name='DOI' value='10.6028/NIST.FIPS.180-4' />
<seriesInfo name="FIPS-180-4," value="Gaithersburg, MD, USA"/>
<annotation> https://csrc.nist.gov/publications/detail/fips/180/4/final<
/annotation>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .2104.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .2104.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .8126.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .8126.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-dtn-
bpbis.xml"/> <!-- [I-D.ietf-dtn-bpbis] RFC-to-be 9171 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-dtn-
bpsec.xml"/> <reference anchor='RFC9171'>
<front>
<title>Bundle Protocol Version 7</title>
<author initials='S' surname='Burleigh' fullname='Scott Burleigh'>
<organization />
</author>
<author initials='K' surname='Fall' fullname='Kevin Fall'>
<organization />
</author>
<author initials="E." surname="Birrane, III" fullname="Edward J. Birrane, III">
<organization />
</author>
<date year='2022' month='January' />
</front>
<seriesInfo name="RFC" value="9171"/>
<seriesInfo name="DOI" value="10.17487/RFC9171"/>
</reference>
<!-- [I-D.ietf-dtn-bpsec] RFC-to-be 9172 -->
<reference anchor='RFC9172'>
<front>
<title>Bundle Protocol Security (BPSec)</title>
<author initials="E." surname="Birrane, III" fullname="Edward J. Birrane, III">
<organization />
</author>
<author initials='K' surname='McKeever' fullname='Kenneth McKeever'>
<organization />
</author>
<date year='2022' month='January' />
</front>
<seriesInfo name="RFC" value="9172"/>
<seriesInfo name="DOI" value="10.17487/RFC9172"/>
</reference>
</references> </references>
<section anchor="vectors" toc="default" numbered="true"> <section anchor="vectors" toc="default" numbered="true">
<name>Examples</name> <name>Examples</name>
<t> This appendix is informative. </t> <t> This appendix is informative. </t>
<t> <t>
This section 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 document) security blocks (using the security contexts defined in this document)
and adding those blocks to a sample bundle. and adding those blocks to a sample bundle.
</t> </t>
<t> <t>
The examples presented in this appendix represent valid constructions of The examples presented in this appendix represent valid constructions of
bundles, security blocks, and the encoding of security context parameters bundles, security blocks, and the encoding of security context parameters
and results. For this reason, they can inform unit test suites and results. For this reason, they can inform unit test suites
for individual implementations as well as interoperability test suites for individual implementations as well as interoperability test suites
amongst implementations. However, these examples do not cover every amongst implementations. However, these examples do not cover every
permutation of security parameters, security results, or use of security permutation of security context parameters, security results, or use of se curity
blocks in a bundle. blocks in a bundle.
</t> </t>
<t> <t>
NOTE: The bundle diagrams in this section are patterned after the bundle d NOTES: </t>
iagrams used in <xref target="I-D.ietf-dtn-bpsec" format="default"/> Section 3.1 <ul>
1 "BSP Block Examples". <li>The bundle diagrams in this appendix are patterned after the bundle
</t> diagrams used in Section <xref target="RFC9172" section="3.11"
<t> sectionFormat="bare">"BPSec Block Examples"</xref> of <xref target="RFC917
NOTE: Figures in this section identified as "(CBOR Diagnostic Notation)" 2"/>.
</li>
<li>
Figures in this appendix identified as "(CBOR Diagnostic Notation)"
are represented using the CBOR diagnostic notation defined in <xref target ="RFC8949" format="default"/>. are represented using the CBOR diagnostic notation defined in <xref target ="RFC8949" format="default"/>.
This notation is used to express CBOR data structures in a manner that ena bles This notation is used to express CBOR data structures in a manner that ena bles
visual inspection. The bundles, security blocks, and security context cont ents visual inspection. The bundles, security blocks, and security context cont ents
in these figures are represented using CBOR structures. In cases where BP blocks in these figures are represented using CBOR structures. In cases where BP blocks
(to include BPSec security blocks) are comprised of a sequence of (to include BPSec security blocks) are comprised of a sequence of
CBOR objects, these objects are represented as a CBOR sequence as defined in CBOR objects, these objects are represented as a CBOR sequence as defined in
<xref target="RFC8742" format="default"/>. <xref target="RFC8742" format="default"/>.
</t> </li>
<t>
NOTE: Examples in this section use the "ipn" URI scheme for EndpointID <li>
naming, as defined in <xref target="I-D.ietf-dtn-bpbis" format="default"/> Examples in this appendix use the "ipn" URI scheme for endpoint ID
. naming, as defined in <xref target="RFC9171" format="default"/>.
</t> </li>
<t> <li>
NOTE: 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 section, unless otherwise noted. security blocks in this appendix, unless otherwise noted.
</t> </li>
</ul>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Example 1: Simple Integrity</name> <name>Example 1 - Simple Integrity</name>
<t> <t>
This example shows the addition of a BIB to a sample bundle This example shows the addition of a BIB to a sample bundle
to provide integrity for the payload block. to provide integrity for the payload block.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Original Bundle</name> <name>Original Bundle</name>
<t> <t>
The following diagram shows the original bundle before the The following diagram shows the original bundle before the
BIB has been added. BIB has been added.
</t> </t>
<figure anchor="ex1_orig_bundle">
<name>Example 1 Original Bundle</name>
<artwork align="center" name="" type="" alt="">
<!--
--> Block Block Block <figure>
<!-- <name>Example 1 - Original Bundle</name>
--> in Bundle Type Number <artwork align="center">
<!-- Block Block Block
-->+========================================+=======+========+ in Bundle Type Number
<!-- +========================================+=======+========+
-->| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
<!-- +----------------------------------------+-------+--------+
-->+----------------------------------------+-------+--------+ | Payload Block | 1 | 1 |
<!-- +----------------------------------------+-------+--------+
-->| Payload Block | 1 | 1 | </artwork>
<!-- </figure>
-->+----------------------------------------+-------+--------+
</artwork>
</figure>
<section anchor="ex_primary_block" numbered="true" toc="default"> <section anchor="ex_primary_block" numbered="true" toc="default">
<name>Primary Block</name> <name>Primary Block</name>
<t> <t>
The BPv7 bundle has no special processing flags and no CRC is The Bundle Protocol version 7 (BPv7) bundle has no special block
provided because the primary block is expected to be protected by and bundle processing control flags, and no CRC is provided
an integrity service BIB using the BIB-HMAC-SHA2 security context. because the primary block is expected to be protected by an
integrity service BIB using the BIB-HMAC-SHA2 security context.
</t> </t>
<t> <t>
The bundle is sourced at the source node ipn:2.1 and destined for 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 the destination node ipn:1.2.
creation time of 0 indicating lack of an accurate clock and a The bundle creation time is set to 0, indicating lack of an accurate clock,
with a
sequence number of 40. The lifetime of the bundle is given as sequence number of 40. The lifetime of the bundle is given as
1,000,000 milliseconds since the bundle creation time. 1,000,000 milliseconds since the bundle creation time.
</t> </t>
<t> <t>
The primary block is provided as follows. The primary block is provided as follows.
</t> </t>
<figure anchor="ex_bdl_prim"> <figure anchor="ex_bdl_prim">
<name>Primary Block (CBOR Diagnostic Notation)</name> <name>Primary Block (CBOR Diagnostic Notation)</name>
<artwork align="left" type="cbor" name="" alt=""><![CDATA[ <sourcecode type="cbor-diag" name=""><![CDATA[
[ [
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 /
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the primary block is:
The CBOR encoding of the primary block is 0x880700008202820102820282
02018202820201820018281a000f4240.
</t> </t>
<sourcecode>
0x88070000820282010282028202018202820201820018281a000f4240
</sourcecode>
</section> </section>
<section anchor="ex_payload_block" numbered="true" toc="default"> <section anchor="ex_payload_block" numbered="true" toc="default">
<name>Payload Block</name> <name>Payload Block</name>
<t> <t>
Other than its use as a source of plaintext for security blocks, Other than its use as a source of plaintext for security blocks,
the payload has no required distinguishing characteristic for the the payload has no required distinguishing characteristic for the
purpose of this example. The sample payload is a 32 byte string purpose of this example. The sample payload is a 35-byte string.
whose value is "Ready Generate a 32 byte payload".
</t> </t>
<t> <t>
The payload is represented in the payload block as a byte string The payload is represented in the payload block as a byte string
of the raw payload string. It is NOT represented as a CBOR text of the raw payload string. It is NOT represented as a CBOR text
string wrapped within a CBOR binary string. The hex value of the string wrapped within a CBOR binary string. The hex value of the
payload "Ready Generate a 32 byte payload" is payload is:
0x52656164792047656e657261746520612033322062797465207061796c6f6164.
</t> </t>
<sourcecode>
0x526561647920746f2067656e657261746520612033322d62797465207061796c6f
6164
</sourcecode>
<t> <t>
The payload block is provided as follows. The payload block is provided as follows.
</t> </t>
<figure> <figure>
<name>Payload Block (CBOR Diagnostic Notation)</name> <name>Payload Block (CBOR Diagnostic Notation)</name>
<artwork align="left" type="cbor" name="" alt=""><![CDATA[ <sourcecode type="cbor-diag" name=""><![CDATA[
[ [
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'
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the payload block is:
The CBOR encoding of the payload block is 0x850101000058205265616479
2047656e657261746520612033322062797465207061796c6f6164.
</t> </t>
<sourcecode>
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle CBOR Representation</name> <name>Bundle CBOR Representation</name>
<t> <t>
A BPv7 bundle is represented as an indefinite-length array consistin g A BPv7 bundle is represented as an indefinite-length array consistin g
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.
</t> </t>
<t> <t>
The CBOR encoding of the original bundle is 0x9f88070000820282010282 028202018202820201820018281a000f42408501010000582052656164792047656e657261746520 612033322062797465207061796c6f6164ff. The CBOR encoding of the original bundle is:
</t> </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Operation Overview</name> <name>Security Operation Overview</name>
<t> <t>
This example adds a BIB to the bundle using the BIB-HMAC-SHA2 security This example adds a BIB to the bundle using the BIB-HMAC-SHA2 security
context to provide an integrity mechanism over the payload block. context to provide an integrity mechanism over the payload block.
</t> </t>
<t> <t>
The following diagram shows the resulting bundle after the The following diagram shows the resulting bundle after the
BIB is added. BIB is added.
</t> </t>
<figure anchor="ex1_res_bundle">
<name>Example 1 Resulting Bundle</name>
<artwork align="center" name="" type="" alt="">
<!--
--> Block Block Block <figure>
<!-- <name>Example 1 - Resulting Bundle</name>
--> in Bundle Type Number <artwork align="center">
<!-- Block Block Block
-->+========================================+=======+========+ in Bundle Type Number
<!-- +========================================+=======+========+
-->| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
<!-- +----------------------------------------+-------+--------+
-->+----------------------------------------+-------+--------+ | Block Integrity Block | 11 | 2 |
<!-- | OP(bib-integrity, target=1) | | |
-->| Bundle Integrity Block | 11 | 2 | +----------------------------------------+-------+--------+
<!-- | Payload Block | 1 | 1 |
-->| OP(bib-integrity, target=1) | | | +----------------------------------------+-------+--------+
<!-- </artwork>
-->+----------------------------------------+-------+--------+ </figure>
<!--
-->| Payload Block | 1 | 1 |
<!--
-->+----------------------------------------+-------+--------+
</artwork>
</figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle Integrity Block</name> <name>Block Integrity Block</name>
<t> <t>
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.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Configuration, Parameters, and Results</name> <name>Configuration, Parameters, and Results</name>
<t> <t>
For this example, the following configuration and security For this example, the following configuration and security context
parameters are used to generate the security results parameters are used to generate the security results
indicated. indicated.
</t> </t>
<t> <t>
This BIB has a single target and includes a single security This BIB has a single target and includes a single security
result: the calculated signature over the payload block. result: the calculated signature over the payload block.
</t> </t>
<figure anchor="ex1_cpr"> <figure anchor="ex1_cpr">
<name>Example 1: Configuration, Parameters, and Results</name> <name>Example 1 - Configuration, Parameters, and Results</name>
<artwork align="center" name="" type="" alt=""> <artwork name="" type="" alt="" align="center">
<!-- Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
<!-- SHA Variant : HMAC 512/512
<!-- Scope Flags : 0x00
<!-- Payload Data: h'526561647920746f2067656e65726174
<!-- 6520612033322d62797465207061796c
<!-- 6f6164'
<!-- IPPT : h'005823526561647920746f2067656e65
<!-- 7261746520612033322d627974652070
<!-- 61796c6f6164'
<!-- Signature : h'3bdc69b3a34a2b5d3a8554368bd1e808
f606219d2a10a846eae3886ae4ecc83c
4ee550fdfb1cc636b904e2f1a73e303d
cd4b6ccece003e95e8164dcc89a156e1'
</artwork> </artwork>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Abstract Security Block</name> <name>Abstract Security Block</name>
<t> <t>
The abstract security block structure of the BIB's The abstract security block structure of the BIB's
block-type-specific-data field for this application is as follows. block-type-specific data field for this application is as follows.
</t> </t>
<figure anchor="ex1_bib_asb"> <figure anchor="ex1_bib_asb">
<name>Example 1: BIB Abstract Security Block (CBOR Diagnostic Nota <name>Example 1 - BIB Abstract Security Block (CBOR Diagnostic Not
tion)</name> ation)</name>
<artwork align="left" type="cbor" name="" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
[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']
]
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BIB block-type-specific data field (the abs
The CBOR encoding of the BIB block-type-specific-data field (the abs tract security block) is:
tract security block) is
0x8101010182028202018282010782030081820158400654d65992803252210e377d
66d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fb
a4b3be2b219074fdd5ea8ef0.
</t> </t>
<sourcecode>
0x810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a8554
368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2f1a7
3e303dcd4b6ccece003e95e8164dcc89a156e1
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Representations</name> <name>Representations</name>
<t> <t>
The BIB wrapping this abstract security block is as follows. The complete BIB is as follows.
</t> </t>
<figure anchor="ex1_bib"> <figure anchor="ex1_bib">
<name>Example 1: BIB (CBOR Diagnostic Notation)</name> <name>Example 1 - BIB (CBOR Diagnostic Notation)</name>
<artwork align="left" type="cbor" name="" alt=""><![CDATA[ <sourcecode type="cbor-diag" name=""><![CDATA[
[ [
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'
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BIB block is:
The CBOR encoding of the BIB block is 0x850b020000585581010101820282
02018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9a
c198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0.
</t> </t>
<sourcecode>
0x850b0200005856810101018202820201828201078203008181820158403bdc69b3
a34a2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1c
c636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Final Bundle</name> <name>Final Bundle</name>
<t> <t>
The CBOR encoding of the full output bundle, with the BIB: 0x9f8807000 0820282010282028202018202820201820018281a000f4240850b020000585581010101820282020 18282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac19 8a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef08501010 000582052656164792047656e657261746520612033322062797465207061796c6f6164ff. The CBOR encoding of the full output bundle, with the BIB:
</t> </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f4240850b0200
005856810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a
8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2
f1a73e303dcd4b6ccece003e95e8164dcc89a156e185010100005823526561647920
746f2067656e657261746520612033322d62797465207061796c6f6164ff
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Example 2: Simple Confidentiality with Key Wrap</name> <name>Example 2 - Simple Confidentiality with Key Wrap</name>
<t> <t>
This example shows the addition of a BCB to a sample bundle This example shows the addition of a BCB to a sample bundle
to provide confidentiality for the payload block. AES key wrap to provide confidentiality for the payload block. AES key wrap
is used to transmit the symmetric key used to generate the is used to transmit the symmetric key used to generate the
security results for this service. security results for this service.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Original Bundle</name> <name>Original Bundle</name>
<t> <t>
The following diagram shows the original bundle before the The following diagram shows the original bundle before the
BCB has been added. BCB has been added.
</t> </t>
<figure anchor="ex2_orig_bundle"> <figure align="center">
<name>Example 2 Original Bundle</name> <name>Example 2 - Original Bundle</name>
<artwork align="center" name="" type="" alt=""> <artwork align="center">
<!-- Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+
</artwork>
</figure>
--> Block Block Block
<!--
--> in Bundle Type Number
<!--
-->+========================================+=======+========+
<!--
-->| Primary Block | N/A | 0 |
<!--
-->+----------------------------------------+-------+--------+
<!--
-->| Payload Block | 1 | 1 |
<!--
-->+----------------------------------------+-------+--------+
</artwork>
</figure>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Primary Block</name> <name>Primary Block</name>
<t> <t>
The primary block used in this example is identical to the primary bl ock The primary block used in this example is identical to the primary bl ock
presented in Example 1 <xref target="ex_primary_block" format="defaul t"/>. presented for Example 1 in <xref target="ex_primary_block" format="de fault"/>.
</t> </t>
<t> <t>
In summary, the CBOR encoding of the primary block is In summary, the CBOR encoding of the primary block is:
0x88070000820282010282028202018202820201820018281a000f4240.
</t> </t>
<sourcecode>
0x88070000820282010282028202018202820201820018281a000f4240
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Payload Block</name> <name>Payload Block</name>
<t> <t>
The payload block used in this example is identical to the payload bl ock The payload block used in this example is identical to the payload bl ock
presented in Example 1 <xref target="ex_payload_block" format="defaul t"/>. presented for Example 1 in <xref target="ex_payload_block" format="de fault"/>.
</t> </t>
<t> <t>
In summary, the CBOR encoding of the payload block is In summary, the CBOR encoding of the payload block is:
0x8501010000582052656164792047656e6572617465206120333220627974652070
61796c6f6164.
</t> </t>
<sourcecode>
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle CBOR Representation</name> <name>Bundle CBOR Representation</name>
<t> <t>
A BPv7 bundle is represented as an indefinite-length array consistin g A BPv7 bundle is represented as an indefinite-length array consistin g
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.
</t> </t>
<t> <t>
The CBOR encoding of the original bundle is The CBOR encoding of the original bundle is:
0x9f88070000820282010282028202018202820201820018281a000f424085010100
00582052656164792047656e657261746520612033322062797465207061796c6f6164ff.
</t> </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Operation Overview</name> <name>Security Operation Overview</name>
<t> <t>
This example adds a BCB using the BCB-AES-GCM security context This example adds a BCB using the BCB-AES-GCM security context
using AES key wrap to provide a confidentiality mechanism over using AES key wrap to provide a confidentiality mechanism over
the payload block and transmit the symmetric key. the payload block and transmit the symmetric key.
</t> </t>
<t> <t>
The following diagram shows the resulting bundle after the The following diagram shows the resulting bundle after the
BCB is added. BCB is added.
</t> </t>
<figure anchor="ex2_res_bundle"> <figure align="center">
<name>Example 2 Resulting Bundle</name> <name>Example 2 - Resulting Bundle</name>
<artwork align="center" name="" type="" alt="">
<!-- <artwork align="center">
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Block Confidentiality Block | 12 | 2 |
| OP(bcb-confidentiality, target=1) | | |
+----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 1 | 1 |
+----------------------------------------+-------+--------+
</artwork>
</figure>
--> Block Block Block
<!--
--> in Bundle Type Number
<!--
-->+========================================+=======+========+
<!--
-->| Primary Block | N/A | 0 |
<!--
-->+----------------------------------------+-------+--------+
<!--
-->| Bundle Confidentiality Block | 12 | 2 |
<!--
-->| OP(bcb-confidentiality, target=1) | | |
<!--
-->+----------------------------------------+-------+--------+
<!--
-->| Payload Block (Encrypted) | 1 | 1 |
<!--
-->+----------------------------------------+-------+--------+
</artwork>
</figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle Confidentiality Block</name> <name>Block Confidentiality Block</name>
<t> <t>
In this example, a BCB is used to encrypt the payload block In this example, a BCB is used to encrypt the payload block, and AES key
and uses AES key wrap to transmit the symmetric key. wrap is used to encode the symmetric key prior to its inclusion in the BCB.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Configuration, Parameters, and Results</name> <name>Configuration, Parameters, and Results</name>
<t> <t>
For this example, the following configuration and security For this example, the following configuration and security context
parameters are used to generate the security results parameters are used to generate the security results
indicated. indicated.
</t> </t>
<t> <t>
This BCB has a single target, the payload block. Three This BCB has a single target -- the payload block. Three
security results are generated: cipher text which security results are generated: ciphertext that
replaces the plain text block-type-specific data to replaces the plaintext block-type-specific data to
encrypt the payload block, an authentication tag, and encrypt the payload block, an authentication tag, and
the AES wrapped key. the AES wrapped key.
</t> </t>
<figure anchor="ex2_cpr"> <figure anchor="ex2_cpr">
<name>Example 2: Configuration, Parameters, and Results</name> <name>Example 2 - Configuration, Parameters, and Results</name>
<artwork align="left" name="" type="" alt=""> <artwork align="center" name="" type="" alt="">
<!-- Content Encryption
<!-- Key: h'71776572747975696f70617364666768'
<!-- Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70'
<!-- IV: h'5477656c7665313231323132'
<!-- AES Variant: A128GCM
<!-- AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892
<!-- 96fabf34d7fae700'
<!-- Scope Flags: 0x00
<!-- Payload Data: h'526561647920746f2067656e65726174
<!-- 6520612033322d62797465207061796c
<!-- 6f6164'
<!-- AAD: h'00'
<!-- Authentication Tag: h'efa4b5ac0108e3816c5606479801bc04'
<!-- Payload Ciphertext: h'3a09c1e63fe23a7f66a59c7303837241
e070b02619fc59c5214a22f08cd70795
e73e9a'
</artwork> </artwork>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Abstract Security Block</name> <name>Abstract Security Block</name>
<t> <t>
The abstract security block structure of the BCB's The abstract security block structure of the BCB's
block-type-specific-data field for this application is as follows. block-type-specific data field for this application is as follows.
</t> </t>
<figure anchor="ex2_bcb_asb"> <figure anchor="ex2_bcb_asb">
<name>Example 2: BCB Abstract Security Block (CBOR Diagnostic Nota <name>Example 2 - BCB Abstract Security Block (CBOR Diagnostic Not
tion)</name> ation)</name>
<artwork align="left" type="cbor" name="" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
[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 /
]
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BCB block-type-specific data field
The CBOR encoding of the BCB block-type-specific-data field (the abstract security block) is:
(the abstract security block) is
0x8101020182028202018482014c5477656c76653132313231328202018203581869
c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b
3b800e73dd97.
</t> </t>
<sourcecode>
0x8101020182028202018482014c5477656c76653132313231328202018203581869
c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150efa4b5
ac0108e3816c5606479801bc04
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Representations</name> <name>Representations</name>
<t> <t>
The BCB wrapping this abstract security block is as follows. The complete BCB is as follows.
</t> </t>
<figure anchor="ex2_bcb"> <figure anchor="ex2_bcb">
<name>Example 2: BCB (CBOR Diagnostic Notation)</name> <name>Example 2 - BCB (CBOR Diagnostic Notation)</name>
<artwork align="left" type="cbor" name="" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
[ [
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'
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BCB block is:
The CBOR encoding of the BCB block is 0x850c020100584f81010201820282
02018482014c5477656c76653132313231328202018203581869c411276fecddc4780df42c8a2af8
9296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e73dd97.
</t> </t>
<sourcecode>
0x850c02010058508101020182028202018482014c5477656c766531323132313282
02018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081
81820150efa4b5ac0108e3816c5606479801bc04
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Final Bundle</name> <name>Final Bundle</name>
<t> <t>
The CBOR encoding of the full output bundle, with the BCB: 0x9f8807000 0820282010282028202018202820201820018281a000f4240850c020100584f81010201820282020 18482014c5477656c76653132313231328202018203581869c411276fecddc4780df42c8a2af8929 6fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e73dd97850101000058203a09c 1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff. The CBOR encoding of the full output bundle, with the BCB:
</t> </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f4240850c0201
0058508101020182028202018482014c5477656c7665313231323132820201820358
1869c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150ef
a4b5ac0108e3816c5606479801bc04850101000058233a09c1e63fe23a7f66a59c73
03837241e070b02619fc59c5214a22f08cd70795e73e9aff
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Example 3: Security Blocks from Multiple Sources</name> <name>Example 3 - Security Blocks from Multiple Sources</name>
<t> <t>
This example shows the addition of a BIB and BCB to This example shows the addition of a BIB and BCB to
a sample bundle. These two security blocks are added a sample bundle. These two security blocks are added
by two different nodes. The BCB is added by the source by two different nodes. The BCB is added by the source
endpoint and the BIB is added by a forwarding node. endpoint, and the BIB is added by a forwarding node.
</t> </t>
<t> <t>
The resulting bundle contains a BCB to encrypt the The resulting bundle contains a BCB to encrypt the
Payload Block and a BIB to provide integrity to the Payload Block and a BIB to provide integrity to the
Primary and Bundle Age Block. primary block and Bundle Age Block.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Original Bundle</name> <name>Original Bundle</name>
<t> <t>
The following diagram shows the original bundle before the The following diagram shows the original bundle before the
security blocks have been added. security blocks have been added.
</t> </t>
<figure anchor="ex3_orig_bundle">
<name>Example 3 Original Bundle</name>
<artwork align="center" name="" type="" alt="">
<!--
--> Block Block Block <figure align="center">
<!-- <name>Example 3 - Original Bundle</name>
--> in Bundle Type Number <artwork align="center">
<!-- Block Block Block
-->+========================================+=======+========+ 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 |
<!-- +----------------------------------------+-------+--------+
-->+----------------------------------------+-------+--------+ </artwork>
<!-- </figure>
-->| Payload Block | 1 | 1 |
<!--
-->+----------------------------------------+-------+--------+
</artwork>
</figure>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Primary Block</name> <name>Primary Block</name>
<t> <t>
The primary block used in this example is identical to the primary bl ock The primary block used in this example is identical to the primary bl ock
presented in Example 1 <xref target="ex_primary_block" format="defaul t"/>. presented for Example 1 in <xref target="ex_primary_block" format="de fault"/>.
</t> </t>
<t> <t>
In summary, the CBOR encoding of the primary block is In summary, the CBOR encoding of the primary block is:
0x88070000820282010282028202018202820201820018281a000f4240.
</t> </t>
<sourcecode>
0x88070000820282010282028202018202820201820018281a000f4240
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle Age Block</name> <name>Bundle Age Block</name>
<t> <t>
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 network determine the age of the bundle. The use of this block is
as recommended because the bundle source does not have an accurate recommended because the bundle source does not have an accurate
clock (as indicated by the DTN time of 0). clock (as indicated by the DTN time of 0).
</t> </t>
<t> <t>
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 forwarded, the bundle age represents the time that has elapsed
from the time the bundle was created to the time it is being prepared from the time the bundle was created to the time it is being prepared
for forwarding. In this case, the value is given as 300 milliseconds. for forwarding. In this case, the value is given as 300 milliseconds.
</t> </t>
<t> <t>
The bundle age extension block is provided as follows. The Bundle Age extension block is provided as follows.
</t> </t>
<figure anchor="ex_bdl_age"> <figure anchor="ex_bdl_age">
<name>Bundle Age Block (CBOR Diagnostic Notation)</name> <name>Bundle Age Block (CBOR Diagnostic Notation)</name>
<artwork align="left" type="cbor" name="" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
[ [
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 /
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the Bundle Age Block is:
The CBOR encoding of the bundle age block is 0x85070200004319012c.
</t> </t>
<sourcecode>
0x85070200004319012c
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Payload Block</name> <name>Payload Block</name>
<t> <t>
The payload block used in this example is identical to the payload bl ock The payload block used in this example is identical to the payload bl ock
presented in Example 1 <xref target="ex_payload_block" format="defaul t"/>. presented for Example 1 in <xref target="ex_payload_block" format="de fault"/>.
</t> </t>
<t> <t>
In summary, the CBOR encoding of the payload block is In summary, the CBOR encoding of the payload block is:
0x8501010000582052656164792047656e6572617465206120333220627974652070
61796c6f6164.
</t> </t>
<sourcecode>
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle CBOR Representation</name> <name>Bundle CBOR Representation</name>
<t> <t>
A BPv7 bundle is represented as an indefinite-length array consistin g A BPv7 bundle is represented as an indefinite-length array consistin g
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.
</t> </t>
<t> <t>
The CBOR encoding of the original bundle is The CBOR encoding of the original bundle is:
0x9f88070000820282010282028202018202820201820018281a000f424085070200
004319012c8501010000582052656164792047656e65726174652061203332206279746520706179
6c6f6164ff.
</t> </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f424085070200
004319012c85010100005823526561647920746f2067656e65726174652061203332
2d62797465207061796c6f6164ff
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Operation Overview</name> <name>Security Operation Overview</name>
<t> <t>
This example provides: This example provides:
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
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 integrity mechanism over the primary block and Bundle Age
block. Block.
</li> </li>
<li> <li>
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.
</li> </li>
</ul> </ul>
<t> <t>
The following diagram shows the resulting bundle after the The following diagram shows the resulting bundle after the
security blocks are added. security blocks are added.
</t> </t>
<figure anchor="ex3_res_bundle">
<name>Example 3 Resulting Bundle</name>
<artwork align="center" name="" type="" alt="">
<!--
--> Block Block Block <figure>
<!-- <name>Example 3 - Resulting Bundle</name>
--> in Bundle Type Number <artwork align="center">
<!-- Block Block Block
-->+========================================+=======+========+ in Bundle Type Number
<!-- +========================================+=======+========+
-->| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
<!-- +----------------------------------------+-------+--------+
-->+----------------------------------------+-------+--------+ | Block Integrity Block | 11 | 3 |
<!-- | OP(bib-integrity, targets=0, 2) | | |
-->| Bundle Integrity Block | 11 | 3 | +----------------------------------------+-------+--------+
<!-- | Block Confidentiality Block | 12 | 4 |
-->| OP(bib-integrity, targets=0, 2) | | | | OP(bcb-confidentiality, target=1) | | |
<!-- +----------------------------------------+-------+--------+
-->+----------------------------------------+-------+--------+ | Extension Block: Bundle Age Block | 7 | 2 |
<!-- +----------------------------------------+-------+--------+
-->| Bundle Confidentiality Block | 12 | 4 | | Payload Block (Encrypted) | 1 | 1 |
<!-- +----------------------------------------+-------+--------+
-->| OP(bcb-confidentiality, target=1) | | | </artwork>
<!-- </figure>
-->+----------------------------------------+-------+--------+
<!--
-->| Extension Block: Bundle Age Block | 7 | 2 |
<!--
-->+----------------------------------------+-------+--------+
<!--
-->| Payload Block (Encrypted) | 1 | 1 |
<!--
-->+----------------------------------------+-------+--------+
</artwork>
</figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle Integrity Block</name> <name>Block Integrity Block</name>
<t> <t>
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 the Bundle Age Block and an additional signature over the
payload block. The BIB is added by a waypoint node, ipn:3.0. payload block. The BIB is added by a waypoint node -- ipn:3.0.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Configuration, Parameters, and Results</name> <name>Configuration, Parameters, and Results</name>
<t> <t>
For this example, the following configuration and security For this example, the following configuration and security context
parameters are used to generate the security results parameters are used to generate the security results
indicated. indicated.
</t> </t>
<t> <t>
This BIB has two security targets and includes two This BIB has two security targets and includes two
security results, holding the calculated signatures over security results, holding the calculated signatures over
the bundle age block and primary block. the Bundle Age Block and primary block.
</t> </t>
<figure anchor="ex3_bib_cpr"> <figure anchor="ex3_bib_cpr">
<name>Example 3: Configuration, Parameters, and Resul <name>Example 3 - Configuration, Parameters, and Results for the B
ts for the BIB</name> IB</name>
<artwork align="left" name="" type="" alt=""> <artwork align="center" name="" type="" alt="">
<!-- Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
<!-- SHA Variant: HMAC 256/256
<!-- Scope Flags: 0x00
<!-- Primary Block Data: h'88070000820282010282028202018202
<!-- 820201820018281a000f4240'
<!-- Bundle Age Block
<!-- Data: h'4319012c'
<!-- Primary Block IPPT: h'00581c88070000820282010282028202
<!-- 018202820201820018281a000f4240'
<!-- Bundle Age Block
<!-- IPPT: h'004319012c'
<!-- Primary Block
<!-- Signature: h'cac6ce8e4c5dae57988b757e49a6dd14
<!-- 31dc04763541b2845098265bc817241b'
Bundle Age Block
Signature: h'3ed614c0d97f49b3633627779aa18a33
8d212bf3c92b97759d9739cd50725596'
</artwork> </artwork>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Abstract Security Block</name> <name>Abstract Security Block</name>
<t> <t>
The abstract security block structure of the BIB's The abstract security block structure of the BIB's
block-type-specific-data field for this application is as follows. block-type-specific data field for this application is as follows.
</t> </t>
<figure anchor="ex3_bib_asb"> <figure anchor="ex3_bib_asb">
<name>Example 3: BIB Abstract Security Block (CBOR Diagnostic Nota <name>Example 3 - BIB Abstract Security Block (CBOR Diagnostic Not
tion)</name> ation)</name>
<artwork align="left" type="cbor" name="" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
[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 /
]
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BIB block-type-specific data field (the abs
The CBOR encoding of the BIB block-type-specific-data field (the abs tract security block) is:
tract security block) is
0x820002010182028203008282010582030082820158208e059b8e71f7218264185a
666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964
668eb131b1ca4800c114206d70d9065c80.
</t> </t>
<sourcecode>
0x8200020101820282030082820105820300828182015820cac6ce8e4c5dae57988b
757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d97f49
b3633627779aa18a338d212bf3c92b97759d9739cd50725596
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Representations</name> <name>Representations</name>
<t> <t>
The BIB wrapping this abstract security block is as follows. The complete BIB is as follows.
</t> </t>
<figure anchor="ex3_bib"> <figure anchor="ex3_bib">
<name>Example 3: BIB (CBOR Diagnostic Notation)</name> <name>Example 3 - BIB (CBOR Diagnostic Notation)</name>
<artwork align="left" type="cbor" name="" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
[ [
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'
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BIB block is:
The CBOR encoding of the BIB block is 0x850b030000585a82000201018202
8203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3c
db6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9
065c80.
</t> </t>
<sourcecode>
0x850b030000585c8200020101820282030082820105820300828182015820cac6ce
8e4c5dae57988b757e49a6dd1431dc04763541b2845098265bc817241b8182015820
3ed614c0d97f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle Confidentiality Block</name> <name>Block Confidentiality Block</name>
<t> <t>
In this example, a BCB is used encrypt the payload In this example, a BCB is used encrypt the payload
block. The BCB is added by the bundle source node, ipn:2.1. block. The BCB is added by the bundle source node, ipn:2.1.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Configuration, Parameters, and Results</name> <name>Configuration, Parameters, and Results</name>
<t> <t>
For this example, the following configuration and security For this example, the following configuration and security context
parameters are used to generate the security results parameters are used to generate the security results
indicated. indicated.
</t> </t>
<t> <t>
This BCB has a single target, the payload block. This BCB has a single target, the payload block.
Two security results are generated: cipher text which Two security results are generated: ciphertext that
replaces the plain text block-type-specific data to replaces the plaintext block-type-specific data to
encrypt the payload block, and an authentication tag. encrypt the payload block and an authentication tag.
</t> </t>
<figure anchor="ex3_bcb_cpr"> <figure anchor="ex3_bcb_cpr">
<name>Example 3: Configuration, Parameters, and Results <name>Example 3 - Configuration, Parameters, and Results for the B
for the BCB</name> CB</name>
<artwork align="left" name="" type="" alt=""> <artwork align="center" name="" type="" alt="">
<!-- Content Encryption
<!-- Key: h'71776572747975696f70617364666768'
<!-- IV: h'5477656c7665313231323132'
<!-- AES Variant: A128GCM
<!-- Scope Flags: 0x00
<!-- Payload Data: h'526561647920746f2067656e65726174
<!-- 6520612033322d62797465207061796c
<!-- 6f6164'
<!-- AAD: h'00'
<!-- Authentication Tag: h'efa4b5ac0108e3816c5606479801bc04'
Payload Ciphertext: h'3a09c1e63fe23a7f66a59c7303837241
e070b02619fc59c5214a22f08cd70795
e73e9a'
</artwork> </artwork>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Abstract Security Block</name> <name>Abstract Security Block</name>
<t> <t>
The abstract security block structure of the BCB's The abstract security block structure of the BCB's
block-type-specific-data field for this application is as follows. block-type-specific data field for this application is as follows.
</t> </t>
<figure anchor="ex3_bcb_asb"> <figure anchor="ex3_bcb_asb">
<name>Example 3: BCB Abstract Security Block (CBOR Diagnostic Nota <name>Example 3 - BCB Abstract Security Block (CBOR Diagnostic Not
tion)</name> ation)</name>
<artwork type="cbor" name="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
[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 /
]
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BCB block-type-specific data field
The CBOR encoding of the BCB block-type-specific-data field (the abstract security block) is:
(the abstract security block) is
0x8101020182028202018382014c5477656c76653132313231328202018204008182
0150da08f4d8936024ad7c6b3b800e73dd97.
</t> </t>
<sourcecode>
0x8101020182028202018382014c5477656c76653132313231328202018204008181
820150efa4b5ac0108e3816c5606479801bc04
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Representations</name> <name>Representations</name>
<t> <t>
The BCB wrapping this abstract security block is as follows. The complete BCB is as follows.
</t> </t>
<figure anchor="ex3_bcb"> <figure anchor="ex3_bcb">
<name>Example 3: BCB (CBOR Diagnostic Notation)</name> <name>Example 3 - BCB (CBOR Diagnostic Notation)</name>
<artwork type="cbor" name="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
[ [
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'
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BCB block is:
The CBOR encoding of the BCB block is 0x850c040100583381010201820282
02018382014c5477656c766531323132313282020182040081820150da08f4d8936024ad7c6b3b80
0e73dd97.
</t> </t>
<sourcecode>
0x850c04010058348101020182028202018382014c5477656c766531323132313282
02018204008181820150efa4b5ac0108e3816c5606479801bc04
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Final Bundle</name> <name>Final Bundle</name>
<t> <t>
The CBOR encoding of the full output bundle, with the BIB and BCB adde d is: The CBOR encoding of the full output bundle, with the BIB and BCB adde d is:
0x9f88070000820282010282028202018202820201820018281a000f4240850b030000 585a820002010182028203008282010582030082820158208e059b8e71f7218264185a666bf3e453 076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb131b1 ca4800c114206d70d9065c80850c04010058338101020182028202018382014c5477656c76653132 3132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd9785070200004319012c85 0101000058203a09c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff.
</t> </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f4240850b0300
00585c8200020101820282030082820105820300828182015820cac6ce8e4c5dae57
988b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9
7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596850c0401005834
8101020182028202018382014c5477656c7665313231323132820201820400818182
0150efa4b5ac0108e3816c5606479801bc0485070200004319012c85010100005823
3a09c1e63fe23a7f66a59c7303837241e070b02619fc59c5214a22f08cd70795e73e
9aff
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Example 4: Security Blocks with Full Scope</name> <name>Example 4 - Security Blocks with Full Scope</name>
<t> <t>
This example shows the addition of a BIB and BCB to This example shows the addition of a BIB and BCB to
a sample bundle. A BIB is added to provide integrity a sample bundle. A BIB is added to provide integrity
over the payload block and a BCB is added for over the payload block, and a BCB is added for
confidentiality over the payload and BIB. confidentiality over the payload and BIB.
</t> </t>
<t> <t>
The integrity scope and additional authentication data The integrity scope and additional authentication data
will bind the primary block, target header, and the will bind the primary block, target header, and the
security header. security header.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Original Bundle</name> <name>Original Bundle</name>
<t> <t>
skipping to change at line 2875 skipping to change at line 2959
<t> <t>
The integrity scope and additional authentication data The integrity scope and additional authentication data
will bind the primary block, target header, and the will bind the primary block, target header, and the
security header. security header.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Original Bundle</name> <name>Original Bundle</name>
<t> <t>
The following diagram shows the original bundle before the The following diagram shows the original bundle before the
security blocks have been added. security blocks have been added.
</t> </t>
<figure anchor="ex4_orig_bundle">
<name>Example 4 Original Bundle</name>
<artwork align="center" name="" type="" alt="">
<!--
--> Block Block Block <figure>
<!-- <name>Example 4 - Original Bundle</name>
--> in Bundle Type Number <artwork align="center">
<!-- Block Block Block
-->+========================================+=======+========+ in Bundle Type Number
<!-- +========================================+=======+========+
-->| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
<!-- +----------------------------------------+-------+--------+
-->+----------------------------------------+-------+--------+ | Payload Block | 1 | 1 |
<!-- +----------------------------------------+-------+--------+
-->| Payload Block | 1 | 1 | </artwork>
<!-- </figure>
-->+----------------------------------------+-------+--------+
</artwork>
</figure>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Primary Block</name> <name>Primary Block</name>
<t> <t>
The primary block used in this example is identical to the primary bl ock The primary block used in this example is identical to the primary bl ock
presented in Example 1 <xref target="ex_primary_block" format="defaul t"/>. presented for Example 1 in <xref target="ex_primary_block" format="de fault"/>.
</t> </t>
<t> <t>
In summary, the CBOR encoding of the primary block is In summary, the CBOR encoding of the primary block is:
0x88070000820282010282028202018202820201820018281a000f4240.
</t> </t>
<sourcecode>
0x88070000820282010282028202018202820201820018281a000f4240
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Payload Block</name> <name>Payload Block</name>
<t> <t>
The payload block used in this example is identical to the payload bl ock The payload block used in this example is identical to the payload bl ock
presented in Example 1 <xref target="ex_payload_block" format="defaul t"/>. presented for Example 1 in <xref target="ex_payload_block" format="de fault"/>.
</t> </t>
<t> <t>
In summary, the CBOR encoding of the payload block is In summary, the CBOR encoding of the payload block is:
0x8501010000582052656164792047656e6572617465206120333220627974652070
61796c6f6164.
</t> </t>
<sourcecode>
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle CBOR Representation</name> <name>Bundle CBOR Representation</name>
<t> <t>
A BPv7 bundle is represented as an indefinite-length array consistin g A BPv7 bundle is represented as an indefinite-length array consistin g
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.
</t> </t>
<t> <t>
The CBOR encoding of the original bundle is The CBOR encoding of the original bundle is:
0x9f88070000820282010282028202018202820201820018281a000f424085010100
00582052656164792047656e657261746520612033322062797465207061796c6f6164ff.
</t> </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Operation Overview</name> <name>Security Operation Overview</name>
<t> <t>
This example provides: This example provides:
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li> <li>
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.
</li> </li>
<li> <li>
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.
</li> </li>
</ul> </ul>
<t> <t>
skipping to change at line 2951 skipping to change at line 3037
integrity mechanism over the payload block. integrity mechanism over the payload block.
</li> </li>
<li> <li>
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.
</li> </li>
</ul> </ul>
<t> <t>
The following diagram shows the resulting bundle after the The following diagram shows the resulting bundle after the
security blocks are added. security blocks are added.
</t> </t>
<figure anchor="ex4_res_bundle">
<name>Example 4 Resulting Bundle</name>
<artwork align="center" name="" type="" alt="">
<!--
--> Block Block Block <figure>
<!-- <name>Example 4 - Resulting Bundle</name>
--> in Bundle Type Number <artwork align="center">
<!-- Block Block Block
-->+========================================+=======+========+ in Bundle Type Number
<!-- +========================================+=======+========+
-->| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
<!-- +----------------------------------------+-------+--------+
-->+----------------------------------------+-------+--------+ | Block Integrity Block (Encrypted) | 11 | 3 |
<!-- | OP(bib-integrity, target=1) | | |
-->| Bundle Integrity Block (Encrypted) | 11 | 3 | +----------------------------------------+-------+--------+
<!-- | Block Confidentiality Block | 12 | 2 |
-->| OP(bib-integrity, target=1) | | | | OP(bcb-confidentiality, targets=1, 3) | | |
<!-- +----------------------------------------+-------+--------+
-->+----------------------------------------+-------+--------+ | Payload Block (Encrypted) | 1 | 1 |
<!-- +----------------------------------------+-------+--------+
-->| Bundle Confidentiality Block | 12 | 2 | </artwork>
<!-- </figure>
-->| OP(bcb-confidentiality, targets=1, 3) | | |
<!--
-->+----------------------------------------+-------+--------+
<!--
-->| Payload Block (Encrypted) | 1 | 1 |
<!--
-->+----------------------------------------+-------+--------+
</artwork>
</figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle Integrity Block</name> <name>Block Integrity Block</name>
<t> <t>
In this example, a BIB is used to carry an integrity In this example, a BIB is used to carry an integrity signature over
signature over the payload block. The IPPT contains the payload block. The IPPT contains the block-type-specific data
the payload block block-type-specific data, primary block data, of the payload block, the primary block data, the payload block
the payload block header, and the BIB header. That is, all header, and the BIB header. That is, all additional headers are
additional headers are included in the IPPT. included in the IPPT.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Configuration, Parameters, and Results</name> <name>Configuration, Parameters, and Results</name>
<t> <t>
For this example, the following configuration and security For this example, the following configuration and security context
parameters are used to generate the security results parameters are used to generate the security results
indicated. indicated.
</t> </t>
<t> <t>
This BIB has a single target and includes a single security This BIB has a single target and includes a single security
result: the calculated signature over the Payload block. result: the calculated signature over the Payload block.
</t> </t>
<figure anchor="ex4_bib_cpr"> <figure anchor="ex4_bib_cpr">
<name>Example 4: Configuration, Parameters, and Resul <name>Example 4 - Configuration, Parameters, and Results for the B
ts for the BIB</name> IB</name>
<artwork align="center" name="" type="" alt=""> <artwork name="" type="" alt="" align="center">
<!-- Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
--> Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' SHA Variant: HMAC 384/384
<!-- Scope Flags: 0x07 (all additional headers)
--> SHA Variant: HMAC 384/384 Primary Block Data: h'88070000820282010282028202018202
<!-- 820201820018281a000f4240'
--> Scope Flags: 0x07 (all additional headers) Payload Data: h'526561647920746f2067656e65726174
<!-- 6520612033322d62797465207061796c
--> Primary Block Data: h'88070000820282010282028202018202 6f6164'
<!-- Payload Header: h'010100'
--> 820201820018281a000f4240 BIB Header: h'0b0300'
<!-- IPPT: h'07880700008202820102820282020182
--> Payload Data: h'52656164792047656e65726174652061 02820201820018281a000f4240010100
<!-- 0b03005823526561647920746f206765
--> 2033322062797465207061796c6f6164' 6e657261746520612033322d62797465
<!-- 207061796c6f6164'
--> Payload Header: h'85010100005820' Payload Signature: h'f75fe4c37f76f046165855bd5ff72fbf
<!-- d4e3a64b4695c40e2b787da005ae819f
--> BIB Header: h'850b0300005845' 0a2e30a2e8b325527de8aefb52e73d71,
<!--
--> Payload Signature: h'07c84d929f83bee4690130729d77a1bd
<!--
--> da9611cd6598e73d0659073ea74e8c27
<!--
--> 523b02193cb8ba64be58dbc556887aca
</artwork> </artwork>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Abstract Security Block</name> <name>Abstract Security Block</name>
<t> <t>
The abstract security block structure of the BIB's The abstract security block structure of the BIB's
block-type-specific-data field for this application is as follows. block-type-specific data field for this application is as follows.
</t> </t>
<figure anchor="ex4_bib_asb"> <figure anchor="ex4_bib_asb">
<name>Example 4: BIB Abstract Security Block (CBOR Diagnostic Nota <name>Example 4 - BIB Abstract Security Block (CBOR Diagnostic Not
tion)</name> ation)</name>
<artwork type="cbor" name="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
[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']
]
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BIB block-type-specific-data field (the abs The CBOR encoding of the BIB block-type-specific data field (the abs
tract security block) is tract security block) is:
0x81010101820282020182820106820307818201583007c84d929f83bee469013072
9d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58dbc556887aca.
</t> </t>
<sourcecode>
0x81010101820282020182820106820307818182015830f75fe4c37f76f046165855
bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8aefb52
e73d71
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Representations</name> <name>Representations</name>
<t> <t>
The BIB wrapping this abstract security block is as follows. The complete BIB is as follows.
</t> </t>
<figure anchor="ex4_bib"> <figure anchor="ex4_bib">
<name>Example 4: BIB (CBOR Diagnostic Notation)</name> <name>Example 4 - BIB (CBOR Diagnostic Notation)</name>
<artwork type="cbor" name="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag" name=""><![CDATA[
[ [
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'
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BIB block is:
The CBOR encoding of the BIB block is 0x850b030000584581010101820282
020182820106820307818201583007c84d929f83bee4690130729d77a1bdda9611cd6598e73d0659
073ea74e8c27523b02193cb8ba64be58dbc556887aca.
</t> </t>
<sourcecode>
0x850b030000584681010101820282020182820106820307818182015830f75fe4c3
7f76f046165855bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b3
25527de8aefb52e73d71
</sourcecode>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bundle Confidentiality Block</name> <name>Block Confidentiality Block</name>
<t> <t>
In this example, a BCB is used encrypt the payload In this example, a BCB is used encrypt the payload
block and the BIB that provides integrity over block and the BIB that provides integrity over
the payload. the payload.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Configuration, Parameters, and Results</name> <name>Configuration, Parameters, and Results</name>
<t> <t>
For this example, the following configuration and security For this example, the following configuration and security context
parameters are used to generate the security results parameters are used to generate the security results
indicated. indicated.
</t> </t>
<t> <t>
This BCB has two targets: the payload block and BIB. Four This BCB has two targets: the payload block and BIB. Four
security results are generated: cipher text which security results are generated: ciphertext that
replaces the plain text block-type-specific data of the replaces the plaintext block-type-specific data of the
payload block, cipher text to encrypt the BIB, and authentication payload block, ciphertext to encrypt the BIB, and authentication
tags for both the payload block and BIB. tags for both the payload block and BIB.
</t> </t>
<figure anchor="ex4_bcb_cpr"> <figure anchor="ex4_bcb_cpr">
<name>Example 4: Configuration, Parameters, and Results <name>Example 4 - Configuration, Parameters, and Results for the B
for the BCB</name> CB</name>
<artwork align="center" name="" type="ascii-art" alt=""> <artwork name="" type="ascii-art" alt="" align="center">
<!-- Key: h'71776572747975696f70617364666768
--> Key: h'71776572747975696f70617364666768 71776572747975696f70617364666768'
<!-- IV: h'5477656c7665313231323132'
--> 71776572747975696f70617364666768' AES Variant: A256GCM
<!-- Scope Flags: 0x07 (All additional headers)
--> IV: h'5477656c7665313231323132' Payload Data: h'526561647920746f2067656e65726174
<!-- 6520612033322d62797465207061796c
--> AES Variant: A256GCM 6f6164'
<!-- BIB Data: h'81010101820282020182820106820307
--> Scope Flags: 0x07 (All additional headers) 818182015830f75fe4c37f76f0461658
<!-- 55bd5ff72fbfd4e3a64b4695c40e2b78
--> Payload Data: h'52656164792047656e65726174652061 7da005ae819f0a2e30a2e8b325527de8
<!-- aefb52e73d71'
--> 2033322062797465207061796c6f6164' Primary Block Data: h'88070000820282010282028202018202
<!-- 820201820018281a000f4240'
--> BIB Data: h'81010101820282020182820106820307 Payload Header: h'010100'
<!-- BIB Header: h'0b0300'
--> 818201583007c84d929f83bee4690130 BCB Header: h'0c0201'
<!-- Payload AAD: h'07880700008202820102820282020182
--> 729d77a1bdda9611cd6598e73d065907 02820201820018281a000f4240010100
<!-- 0c0201'
--> 3ea74e8c27523b02193cb8ba64be58db BIB AAD: h'07880700008202820102820282020182
<!-- 02820201820018281a000f42400b0300
--> c556887aca 0c0201'
<!-- Payload Block
--> BIB Authentication Tag: h'd2c51cb2481792dae8b21d848cede99b'
<!-- BIB
--> Authentication Tag: h'c95ed4534769b046d716e1cdfd00830e' Authentication Tag: h'220ffc45c8a901999ecc60991dd78b29'
<!-- Payload Ciphertext: h'90eab6457593379298a8724e16e61f83
--> Payload Block 7488e127212b59ac91f8a86287b7d076
<!-- 30a122'
--> Authentication Tag: h'0e365c700e4bb19c0d991faff5345aff' BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0
<!-- 902902064a2983910c4fb2340790bf42
--> Payload Ciphertext: h'90eab64575930498d6aa654107f15e96 0a7d1921d5bf7c4721e02ab87a93ab1e
<!-- 0b75cf62e4948727c8b5dae46ed2af05
--> 319bb227706000abc8fcac3b9bb9c87e' 439b88029191'
<!--
--> BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0
<!--
--> 902a815f221ebc837a134efc13bfa82a
<!--
--> 2d5d317747da3eb54acef4ca839bd961
<!--
--> 487284404259b60be12b8aed2f3e8a36
<!--
--> 2836529f66'
</artwork> </artwork>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Abstract Security Block</name> <name>Abstract Security Block</name>
<t> <t>
The abstract security block structure of the BCB's The abstract security block structure of the BCB's
block-type-specific-data field for this application is as follows. block-type-specific data field for this application is as follows.
</t> </t>
<figure anchor="ex4_bcb_asb"> <figure anchor="ex4_bcb_asb">
<name>Example 4: BCB Abstract Security Block (CBOR Diagnostic Nota <name>Example 4 - BCB Abstract Security Block (CBOR Diagnostic Not
tion)</name> ation)</name>
<artwork type="cbor" name="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
[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 /
]
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BCB block-type-specific-data field The CBOR encoding of the BCB block-type-specific data field
(the abstract security block) is (the abstract security block) is:
0x820301020182028202018382014c5477656c76653132313231328202038204078282 </t>
0150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff. <sourcecode>
</t> 0x820301020182028202018382014c5477656c766531323132313282020382040782
81820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792dae8b2
1d848cede99b
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Representations</name> <name>Representations</name>
<t> <t>
The BCB wrapping this abstract security block is as follows. The complete BCB is as follows.
</t> </t>
<figure anchor="ex4_bcb"> <figure anchor="ex4_bcb">
<name>Example 4: BCB (CBOR Diagnostic Notation)</name> <name>Example 4 - BCB (CBOR Diagnostic Notation)</name>
<artwork type="cbor" name="" align="left" alt=""><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
[ [
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'
] ]
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The CBOR encoding of the BCB block is:
</t>
<sourcecode>
0x850c0201005849820301020182028202018382014c5477656c7665313231323132
8202038204078281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51c
b2481792dae8b21d848cede99b
</sourcecode>
The CBOR encoding of the BCB block is 0x850c02010058478203010201820282
02018382014c5477656c766531323132313282020382040782820150c95ed4534769b046d716e1cd
fd00830e8201500e365c700e4bb19c0d991faff5345aff.
</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Final Bundle</name> <name>Final Bundle</name>
<t> <t>
The CBOR encoding of the full output bundle, with the security blocks ad The CBOR encoding of the full output bundle, with the security blocks ad
ded and payload block and BIB encrypted is: 0x9f88070000820282010282028202018202 ded and payload block and BIB encrypted is:</t>
820201820018281a000f4240850b0300005845438ed6208eb1c1ffb94d952175167df0902a815f22 <sourcecode>
1ebc837a134efc13bfa82a2d5d317747da3eb54acef4ca839bd961487284404259b60be12b8aed2f 0x9f88070000820282010282028202018202820201820018281a000f4240850b0300
3e8a362836529f66 850c0201005847820301020182028202018382014c5477656c7665313231323 005846438ed6208eb1c1ffb94d952175167df0902902064a2983910c4fb2340790bf
13282020382040782820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d9 420a7d1921d5bf7c4721e02ab87a93ab1e0b75cf62e4948727c8b5dae46ed2af0543
91faff5345aff8501010000582090eab64575930498d6aa654107f15e96319bb227706000abc8fca 9b88029191850c0201005849820301020182028202018382014c5477656c76653132
c3b9bb9c87eff. 313231328202038204078281820150220ffc45c8a901999ecc60991dd78b29818201
</t> 50d2c51cb2481792dae8b21d848cede99b8501010000582390eab6457593379298a8
724e16e61f837488e127212b59ac91f8a86287b7d07630a122ff
</sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="cddl" toc="default" numbered="true"> <section anchor="cddl" toc="default" numbered="true">
<name>CDDL Expression</name> <name>CDDL Expression</name>
<t> <t>
For informational purposes, Brian Sipos has kindly provided an expression For informational purposes, this section contains an
of the IPPT and AAD structures using the Concise Data expression of the IPPT and AAD structures using the Concise Data
Definition Language (CDDL). That CDDL expression is presented below. Definition Language (CDDL).
</t> </t>
<t> <t>NOTES:</t>
Note that wherever the CDDL expression is in disagreement with the textual <ul spacing="normal">
representation of <li>Wherever the CDDL expression is in disagreement with the textual repre
sentation of
the security block specification presented in earlier sections of this doc ument, the security block specification presented in earlier sections of this doc ument,
the textual representation rules. the textual representation rules.
</t> </li>
<t> <li>
Note that the structure of BP bundles and BPSec security blocks are provid The structure of BP bundles and BPSec security blocks are provided by othe
ed by other r
specifications and this section only provides the CDDL expression for stru specifications; this appendix only provides the CDDL expression for struct
ctures uniquely ures uniquely
defined in this specification. Items related to elements of a bundle, such as "primary-block", defined in this specification. Items related to elements of a bundle, such as "primary-block",
are defined in Appendix B of the Bundle Protocol Version 7 <xref target="I are defined in <xref target="RFC9171" sectionFormat="of" section="B">the B
-D.ietf-dtn-bpbis" format="default"/>. undle Protocol version 7</xref>.
</t> </li>
<t> <li>
Note that the CDDL itself does not have the concept of unadorned CBOR sequ The CDDL itself does not have the concept of unadorned CBOR sequences as
ences as
a top-level subject of a specification. The current best practice, as docu mented in a top-level subject of a specification. The current best practice, as docu mented in
Section 4.1 of <xref target="RFC8742" format="default"/>, requires represe nting the sequence as an <xref target="RFC8742" sectionFormat="of" section="4.1"/>, requires repres enting the sequence as an
array with a comment in the CDDL noting that the array represents a CBOR s equence. array with a comment in the CDDL noting that the array represents a CBOR s equence.
</t> </li>
</ul>
<figure anchor="appendix_b"> <figure anchor="appendix_b">
<name>IPPT and AAD Expressions</name> <name>IPPT and AAD Expressions</name>
<artwork type="cbor" name="" align="left" alt=""><![CDATA[ <sourcecode type="cddl" name=""><![CDATA[
start = scope / AAD-list / IPPT-list ; satisfy CDDL decoders start = scope / AAD-list / IPPT-list ; satisfy CDDL decoders
scope = uint .bits scope-flags scope = uint .bits scope-flags
scope-flags = &( scope-flags = &(
has-primary-ctx: 0, has-primary-ctx: 0,
has-target-ctx: 1, has-target-ctx: 1,
has-security-ctx: 2, has-security-ctx: 2,
) )
; 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
block-metadata = ( block-metadata = (
block-type-code: uint, block-type-code: uint,
block-number: uint, block-number: uint,
block-control-flags, block-control-flags,
) )
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="contr" toc="default" numbered="true"> <section anchor="contr" toc="default" numbered="false">
<name>Acknowledgements</name> <name>Acknowledgments</name>
<t> <t>
Amy Alford of the Johns Hopkins University Applied Physics <contact fullname="Amy Alford"/> of the Johns Hopkins University Applie d Physics
Laboratory contributed useful review and analysis of these Laboratory contributed useful review and analysis of these
security contexts. security contexts.
</t> </t>
<t><contact fullname="Brian Sipos"/> kindly provided the CDDL expression i
n <xref target="cddl"/>.
</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 531 change blocks. 
1233 lines changed or deleted 1369 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/