draft-ietf-dtn-bpsec-default-sc-04.txt   draft-ietf-dtn-bpsec-default-sc-05.txt 
Delay-Tolerant Networking E. Birrane Delay-Tolerant Networking E. Birrane
Internet-Draft JHU/APL Internet-Draft A. White
Intended status: Standards Track April 11, 2021 Intended status: Standards Track S. Heiner
Expires: October 13, 2021 Expires: October 28, 2021 JHU/APL
April 26, 2021
BPSec Default Security Contexts BPSec Default Security Contexts
draft-ietf-dtn-bpsec-default-sc-04 draft-ietf-dtn-bpsec-default-sc-05
Abstract Abstract
This document defines default integrity and confidentiality security This document defines default integrity and confidentiality security
contexts that may be used with the Bundle Protocol Security Protocol contexts that may be used with the Bundle Protocol Security Protocol
(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 used for both testing the interoperability of BPSec implementations
and for providing basic security operations when no other security and for providing basic security operations when no other security
contexts are defined or otherwise required for a network. contexts are defined or otherwise required for a network.
skipping to change at page 1, line 35 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 13, 2021. This Internet-Draft will expire on October 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Integrity Security Context BIB-HMAC-SHA2 . . . . . . . . . . 3 3. Integrity Security Context BIB-HMAC-SHA2 . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. SHA Variant . . . . . . . . . . . . . . . . . . . . . 6 3.3.1. SHA Variant . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 6 3.3.2. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 7
3.3.3. Integrity Scope Flags . . . . . . . . . . . . . . . . 7 3.3.3. Integrity Scope Flags . . . . . . . . . . . . . . . . 7
3.3.4. Enumerations . . . . . . . . . . . . . . . . . . . . 7 3.3.4. Enumerations . . . . . . . . . . . . . . . . . . . . 8
3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Key Considerations . . . . . . . . . . . . . . . . . . . 8 3.5. Key Considerations . . . . . . . . . . . . . . . . . . . 8
3.6. Canonicalization Algorithms . . . . . . . . . . . . . . . 8 3.6. Canonicalization Algorithms . . . . . . . . . . . . . . . 9
3.7. Processing . . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Processing . . . . . . . . . . . . . . . . . . . . . . . 10
3.7.1. Keyed Hash Generation . . . . . . . . . . . . . . . . 9 3.7.1. Keyed Hash Generation . . . . . . . . . . . . . . . . 10
3.7.2. Keyed Hash Verification . . . . . . . . . . . . . . . 10 3.7.2. Keyed Hash Verification . . . . . . . . . . . . . . . 11
4. Security Context BCB-AES-GCM . . . . . . . . . . . . . . . . 11 4. Security Context BCB-AES-GCM . . . . . . . . . . . . . . . . 12
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 14 4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 14
4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 14 4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 15
4.3.3. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 15 4.3.3. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 15
4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 15 4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 16
4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 16 4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 16
4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 16 4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 17
4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 17 4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 17
4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 17 4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 18
4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 18 4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 18
4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 19 4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 19
4.7.1. Cipher text related calculations . . . . . . . . . . 19 4.7.1. Cipher text related calculations . . . . . . . . . . 19
4.7.2. Additional Authenticated Data . . . . . . . . . . . . 20 4.7.2. Additional Authenticated Data . . . . . . . . . . . . 20
4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 20 4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 21
4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 20 4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 21
4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 22 4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
5.1. Security Context Identifiers . . . . . . . . . . . . . . 23 5.1. Security Context Identifiers . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6.1. Key Handling . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Key Management . . . . . . . . . . . . . . . . . . . . . 24
6.2. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Key Handling . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 24 6.3. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Normative References . . . . . . . . . . . . . . . . . . . . 25 6.4. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Normative References . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28
A.1. Example 1: Simple Integrity . . . . . . . . . . . . . . . 28
A.1.1. Original Bundle . . . . . . . . . . . . . . . . . . . 28
A.1.2. Security Operation Overview . . . . . . . . . . . . . 30
A.1.3. Bundle Integrity Block . . . . . . . . . . . . . . . 31
A.1.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 32
A.2. Example 2: Simple Confidentiality with Key Wrap . . . . . 33
A.2.1. Original Bundle . . . . . . . . . . . . . . . . . . . 33
A.2.2. Security Operation Overview . . . . . . . . . . . . . 34
A.2.3. Bundle Confidentiality Block . . . . . . . . . . . . 34
A.2.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 36
A.3. Example 3: Security Blocks from Multiple Sources . . . . 36
A.3.1. Original Bundle . . . . . . . . . . . . . . . . . . . 36
A.3.2. Security Operation Overview . . . . . . . . . . . . . 38
A.3.3. Bundle Integrity Block . . . . . . . . . . . . . . . 39
A.3.4. Bundle Confidentiality Block . . . . . . . . . . . . 41
A.3.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 42
A.4. Example 4: Security Blocks with Full Scope . . . . . . . 42
A.4.1. Original Bundle . . . . . . . . . . . . . . . . . . . 42
A.4.2. Security Operation Overview . . . . . . . . . . . . . 43
A.4.3. Bundle Integrity Block . . . . . . . . . . . . . . . 44
A.4.4. Bundle Confidentiality Block . . . . . . . . . . . . 46
A.4.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 47
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec] The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec]
specification provides inter-bundle integrity and confidentiality specification provides inter-bundle integrity and confidentiality
operations for networks deploying the Bundle Protocol (BP) operations for networks deploying the Bundle Protocol (BP)
[I-D.ietf-dtn-bpbis]. BPSec defines BP extension blocks to carry [I-D.ietf-dtn-bpbis]. BPSec defines BP extension blocks to carry
security information produced under the auspices of some security security information produced under the auspices of some security
context. context.
skipping to change at page 24, line 14 skipping to change at page 24, line 34
6. Security Considerations 6. Security Considerations
Security considerations specific to a single security context are Security considerations specific to a single security context are
provided in the description of that context. This section discusses provided in the description of that context. This section discusses
security considerations that should be evaluated by implementers of security considerations that should be evaluated by implementers of
any security context described in this document. Considerations may any security context described in this document. Considerations may
also be found in documents listed as normative references and they also be found in documents listed as normative references and they
should also be reviewed by security context implementors. should also be reviewed by security context implementors.
6.1. Key Handling 6.1. Key Management
In addition to the key considerations listed in each security The delayed and disrupted nature of DTNs complicates the process of
context, the following also apply to the generation, transmission, key management because there may not be reliable, timely round-trip
and use of keys associated with all of the security contexts defined exchange between security sources, security verifiers, and security
in this document. acceptors in the network. This is true when there is a substantial
signal propagation delay between nodes, when nodes are in a highly
challenged communications environment, and when nodes do not support
bi-directional communication.
In these environments, key establishment protocols that rely on
round-trip information exchange may not converge on a shared secret
in a timely manner (or at all). Also, key revocation or key
verification mechanisms that rely on access to a centralized
authority (such as a certificate authority) may similarly fail in the
stressing conditions of a DTN.
For these reasons, the default security contexts described in this
document rely on symmetric key cryptographic mechanisms because
asymmetric key infrastructure (such as a public key infrastructure)
is impractical in this environment. This extends to any asymmetric-
key mechanism for key derivation, key exchange, or key revocation.
BPSec assumes that "key management is handled as a separate part of
network management" [I-D.ietf-dtn-bpsec]. This assumption is also
made by the security contexts defined in this document which do not
define new protocols for key derivation, exchange of key-encrypting
keys, revocation of existing keys, or the security configuration or
policy used to select certain keys for certain security operations.
Nodes using these security contexts must be able to perform the
following activities, independent of the construction, transmission,
and processing of BPSec security blocks.
Establish shared key-encrypting-keys with other nodes in the
network using an out-of-band mechanism. This may include pre-
sharing of key encryption keys or the use of traditional key
establishment mechanisms prior to the exchange of BPsec security
blocks.
Determine when a key is considered exhausted and no longer to be
used in the generation, verification, or acceptance of a security
block.
Determine when a key is considered invalid and no longer to be
used in the generation, verification, or acceptance of a security
block. Such revocations can be based on a variety of mechanisms
to include local security policy, time relative to the generation
or use of the key, or as specified through network management.
Determine, through an out-of-band mechanism such as local security
policy, what keys are to be used for what security blocks. This
includes the selection of which key should be used in the
evaluation of a security block received by a security verifier or
a security acceptor.
The failure to provide effective key management techniques
appropriate for the operational networking environment can result in
the compromise of those unmanaged keys and the loss of security
services in the network.
6.2. Key Handling
Once generated, keys should be handled as follows.
It is strongly RECOMMENDED that implementations protect keys both It is strongly RECOMMENDED that implementations protect keys both
when they are stored and when they are transmitted. when they are stored and when they are transmitted.
In the event that a key is compromised, any security operations In the event that a key is compromised, any security operations
using a security context associated with that key SHOULD also be using a security context associated with that key SHOULD also be
considered compromised. This means that the BIB-HMAC-SHA2 considered compromised. This means that the BIB-HMAC-SHA2
security context SHOULD NOT provide integrity when used with a security context SHOULD NOT provide integrity when used with a
compromised key and BCB-AES-GCM SHOULD NOT provide confidentiality compromised key and BCB-AES-GCM SHOULD NOT provide confidentiality
when used with a compromised key. when used with a compromised key.
The same key SHOULD NOT be used for different algorithms as doing The same key SHOULD NOT be used for different algorithms as doing
so may leak information about the key. so may leak information about the key.
Unless otherwise specified, the security contexts provided in this 6.3. AES GCM
document do not mandate any specific method for key exchange,
encryption, or encapsulation. The derivation of an appropriate
key is considered separate from the application of the
authenticated confidentiality service provided by this context.
6.2. AES GCM
There are a significant number of considerations related to the use There are a significant number of considerations related to the use
of the GCM mode of AES to provide a confidentiality service. These of the GCM mode of AES to provide a confidentiality service. These
considerations are provided in Section 4.6 as part of the considerations are provided in Section 4.6 as part of the
documentation of the BCB-AES-GCM security context. documentation of the BCB-AES-GCM security context.
6.3. Bundle Fragmentation 6.4. Bundle Fragmentation
Bundle fragmentation may prevent security services in a bundle from Bundle fragmentation may prevent security services in a bundle from
being verified after a bundle is fragmented and before the bundle is being verified after a bundle is fragmented and before the bundle is
re-assembled. Examples of potential issues include the following. re-assembled. Examples of potential issues include the following.
If a security block and its security target do not exist in the If a security block and its security target do not exist in the
same fragment, then the security block cannot be processed until same fragment, then the security block cannot be processed until
the bundle is re-assembled. If a fragment includes an encrypted the bundle is re-assembled. If a fragment includes an encrypted
target block, but not its BCB, then a receiving bundle processing target block, but not its BCB, then a receiving bundle processing
agent (BPA) will not know that the target block has been agent (BPA) will not know that the target block has been
skipping to change at page 26, line 23 skipping to change at page 27, line 45
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[SHS] US NIST, "Secure Hash Standard (SHS).", FIPS- [SHS] US NIST, "Secure Hash Standard (SHS).", FIPS-
180-4, Gaithersburg, MD, USA, August 2015. 180-4, Gaithersburg, MD, USA, August 2015.
https://csrc.nist.gov/publications/detail/fips/180/4/final https://csrc.nist.gov/publications/detail/fips/180/4/final
Appendix A. Acknowledgements Appendix A. Examples
This appendix is informative.
This section presents a series of examples of constructing BPSec
security blocks (using the security contexts defined in this
document) and adding those blocks to a sample bundle.
The examples presented in this appendix represent valid constructions
of bundles, security blocks, and the encoding of security context
parameters and results. For this reason, they may inform unit test
suites for individual implementations as well as interoperability
test suites amongst implementations. However, these examples do not
cover every permutation of security parameters, security results, or
use of security blocks in a bundle.
NOTE: Figures in this section identified as "(CDDL)" are represented
using the Concise Data Definition Language (CDDL) [RFC8610]. The
CDDL is used to express CBOR data structures and its representation
is used here as bundles, security blocks, and contents within
security blocks are all represented using CBOR structures.
NOTE: Examples in this section use the "ipn" URI scheme for
EndpointID naming, as defined in [I-D.ietf-dtn-bpbis].
NOTE: The bundle source is presumed to be the security source for all
security blocks in this section, unless otherwise noted.
A.1. Example 1: Simple Integrity
This example shows the addition of a BIB to a sample bundle to
provide integrity for the payload block.
A.1.1. Original Bundle
The following diagram shows the original bundle before the BIB has
been added.
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Payload Block | 0 | 1 |
+----------------------------------------+-------+--------+
Figure 1: Example 1 Original Bundle
A.1.1.1. Primary Block
The BPv7 bundle has no special processing flags and no CRC is
provided because the primary block is expected to be protected by an
integrity service BIB using the BIB-HMAC-SHA2 security context.
The bundle is sourced at the source node ipn:2.1 and destined for the
destination node ipn:1.2. The bundle creation time uses a DTN
creation time of 0 indicating lack of an accurate clock and a
sequence number of 40. The lifetime of the bundle is given as
1,000,000 milliseconds since the bundle creation time.
The primary block is provided as follows.
[
7, / BP version /
0, / flags /
0, / CRC type /
[2, [1,2]], / destination (ipn:1.2) /
[2, [2,1]], / source (ipn:2.1) /
[2, [2,1]], / report-to (ipn:2.1) /
[0, 40], / timestamp /
1000000 / lifetime /
]
Figure 2: Primary Block (CDDL)
The CBOR encoding of the primary block is
0x88070000820282010282028202018202820201820018281a000f4240.
A.1.1.2. Payload Block
Other than its use as a source of plaintext for security blocks, the
payload has no required distinguishing characteristic for the purpose
of this example. The sample payload is a 32 byte string whose value
is "Ready Generate a 32 byte payload".
The payload is represented in the payload block as a byte string of
the raw payload string. It is NOT represented as a CBOR text string
wrapped within a CBOR binary string. The hex value of the payload
"Ready Generate a 32 byte payload" is
0x52656164792047656e657261746520612033322062797465207061796c6f6164.
The payload block is provided as follows.
[
1, / type code: Payload block /
1, / block number /
0, / block processing flags /
0, / CRC Type /
h'52656164792047656e65726174652061 / type-specific-data: payload /
2033322062797465207061796c6f6164'
]
Payload Block (CDDL)
The CBOR encoding of the payload block is 0x8501010000582052656164792
047656e657261746520612033322062797465207061796c6f6164.
A.1.1.3. Bundle CBOR Representation
A BPv7 bundle is represented as an indefinite-length array consisting
of the blocks comprising the bundle, with a terminator character at
the end.
The CBOR encoding of the original bundle is 0x9f880700008202820102820
28202018202820201820018281a000f42408501010000582052656164792047656e65
7261746520612033322062797465207061796c6f6164ff.
A.1.2. Security Operation Overview
This example adds a BIB to the bundle using the BIB-HMAC-SHA2
security context to provide an integrity mechanism over the payload
block.
The following diagram shows the resulting bundle after the BIB is
added.
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Bundle Integrity Block | 11 | 2 |
| OP(bib-integrity, target=1) | | |
+----------------------------------------+-------+--------+
| Payload Block | 0 | 1 |
+----------------------------------------+-------+--------+
Figure 3: Example 1 Resulting Bundle
A.1.3. Bundle Integrity Block
In this example, a BIB is used to carry an integrity signature over
the payload block.
A.1.3.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters
are used to generate the security results indicated.
This BIB has a single target and includes a single security result:
the calculated signature over the payload block.
Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
SHA Variant : HMAC 512/512
Scope Flags : 0
Payload Data: h'52656164792047656e65726174652061
2033322062797465207061796c6f6164'
Signature : h'd8e7c3be29effa8779e7dcb0d3cadf53
39df50ebd27b9054f197c8ea9864b0a3
35a0636213e5d4a9c95504f261d91a2f
22757112c95e3587a76b4228361803e8'
Figure 4: Example 1: Configuration, Parameters, and Results
A.1.3.2. Abstract Security Block
The abstract security block structure of the BIB's block-type-
specific-data field for this application is as follows.
[1], / Security Target /
1, / Security Context ID - BIB-HMAC-SHA2 /
1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 2 Parameters /
[1, 7], / SHA Variant - HMAC 512/512 /
[3, 0] / Scope Flags - No Additional Scope /
],
[ / Security Results: 1 Result /
[1, h'd8e7c3be29effa8779e7dcb0d3cadf5339df50ebd27b9054f197c8ea9864
b0a335a0636213e5d4a9c95504f261d91a2f22757112c95e3587a76b4228
361803e8']
]
Figure 5: Example 1: BIB Abstract Security Block (CDDL)
The CBOR encoding of the BIB block-type-specific-data field (the
abstract security block) is 0x810101018202820201828201078203008182015
840d8e7c3be29effa8779e7dcb0d3cadf5339df50ebd27b9054f197c8ea9864b0a335
a0636213e5d4a9c95504f261d91a2f22757112c95e3587a76b4228361803e8.
A.1.3.3. Representations
The BIB wrapping this abstract security block is as follows.
[
11, / type code /
2, / block number /
0, / flags /
0, / CRC type /
h'810101018202820201828201078203008182015840d8e7c3be29effa8779e7dcb
0d3cadf5339df50ebd27b9054f197c8ea9864b0a335a0636213e5d4a9c95504f2
61d91a2f22757112c95e3587a76b4228361803e8',
]
Figure 6: Example 1: BIB (CDDL)
The CBOR encoding of the BIB block is 0x850b0200005855810101018202820
201828201078203008182015840d8e7c3be29effa8779e7dcb0d3cadf5339df50ebd2
7b9054f197c8ea9864b0a335a0636213e5d4a9c95504f261d91a2f22757112c95e358
7a76b4228361803e8.
A.1.4. Final Bundle
The CBOR encoding of the full output bundle, with the BIB: 0x9F880700
00820282010282028202018202820201820018281a000f4240850b020000585581010
1018202820201828201078203008182015840d8e7c3be29effa8779e7dcb0d3cadf53
39df50ebd27b9054f197c8ea9864b0a335a0636213e5d4a9c95504f261d91a2f22757
112c95e3587a76b4228361803e8.
A.2. Example 2: Simple Confidentiality with Key Wrap
This example shows the addition of a BCB to a sample bundle to
provide confidentiality for the payload block. AES key wrap is used
to transmit the symmetric key used to generate the security results
for this service.
A.2.1. Original Bundle
The following diagram shows the original bundle before the BCB has
been added.
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Payload Block | 0 | 1 |
+----------------------------------------+-------+--------+
Figure 7: Example 2 Original Bundle
A.2.1.1. Primary Block
The primary block used in this example is identical to the primary
block presented in Example 1 Appendix A.1.1.1.
In summary, the CBOR encoding of the primary block is
0x88070000820282010282028202018202820201820018281a000f4240.
A.2.1.2. Payload Block
The payload block used in this example is identical to the payload
block presented in Example 1 Appendix A.1.1.2.
In summary, the CBOR encoding of the payload block is 0x8501010000582
052656164792047656e657261746520612033322062797465207061796c6f6164.
A.2.1.3. Bundle CBOR Representation
A BPv7 bundle is represented as an indefinite-length array consisting
of the blocks comprising the bundle, with a terminator character at
the end.
The CBOR encoding of the original bundle is 0x9f880700008202820102820
28202018202820201820018281a000f42408501010000582052656164792047656e65
7261746520612033322062797465207061796c6f6164ff.
A.2.2. Security Operation Overview
This example adds a BCB using the BCB-AES-GCM security context using
AES key wrap to provide a confidentiality mechanism over the payload
block and transmit the symmetric key.
The following diagram shows the resulting bundle after the BCB is
added.
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Bundle Confidentiality Block | 12 | 2 |
| OP(bcb-confidentiality, target=1) | | |
+----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 0 | 1 |
+----------------------------------------+-------+--------+
Figure 8: Example 2 Resulting Bundle
A.2.3. Bundle Confidentiality Block
In this example, a BCB is used to encrypt the payload block and uses
AES key wrap to transmit the symmetric key.
A.2.3.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters
are used to generate the security results indicated.
This BCB has a single target, the payload block. Three security
results are generated: cipher text which replaces the plain text
block-type-specific data to encrypt the payload block, an
authentication tag, and the AES wrapped key.
Content Encryption
Key: h'71776572747975696f70617364666768'
Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70'
IV: h'5477656c7665313231323132'
AES Variant: A128GCM
AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892
96fabf34d7fae700'
Scope Flags: 0
Payload Data: h'52656164792047656e65726174652061
2033322062797465207061796c6f6164'
Authentication Tag: h'689b98e649ae3b554e98aa2ae8f801eb'
Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354
a563e32648b700c2784e26a990d91f9d'
Figure 9: Example 2: Configuration, Parameters, and Results
A.2.3.2. Abstract Security Block
The abstract security block structure of the BCB's block-type-
specific-data field for this application is as follows.
[1], / Security Target /
2, / Security Context ID - BCB-AES-GCM /
1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 4 Parameters /
[1, h'5477656c7665313231323132'], / Initialization Vector /
[2, 1], / AES Variant - A128GCM /
[3, h'69c411276fecddc4780df42c8a / AES wrapped key /
2af89296fabf34d7fae700'],
[4, 0] / Scope Flags - No extra scope/
],
[ / Security Results: 1 Result /
[1, h'689b98e649ae3b554e98aa2ae8f801eb'] / Payload Auth. Tag /
]
Figure 10: Example 2: BCB Abstract Security Block (CDDL)
The CBOR encoding of the BCB block-type-specific-data field (the
abstract security block) is 0x8101020182028202018482014c5477656c76653
132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fa
e70082040081820150689b98e649ae3b554e98aa2ae8f801eb.
A.2.3.3. Representations
The BCB wrapping this abstract security block is as follows.
[
12, / type code /
2, / block number /
1, / flags - block must be replicated in every fragment /
0, / CRC type /
h'8101020182028202018482014c5477656c766531323132313282020182035818
69c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008182015068
9b98e649ae3b554e98aa2ae8f801eb'
]
Figure 11: Example 2: BCB (CDDL)
The CBOR encoding of the BCB block is 0x850c020100584f810102018202820
2018482014c5477656c76653132313231328202018203581869c411276fecddc4780d
f42c8a2af89296fabf34d7fae70082040081820150689b98e649ae3b554e98aa2ae8f
801eb.
A.2.4. Final Bundle
The CBOR encoding of the full output bundle, with the BCB: 0x9f880700
00820282010282028202018202820201820018281a000f4240850c020100584f81010
20182028202018482014c5477656c76653132313231328202018203581869c411276f
ecddc4780df42c8a2af89296fabf34d7fae70082040081820150689b98e649ae3b554
e98aa2ae8f801eb850101000058203a09c1e63fe2097528a78b7c12943354a563e326
48b700c2784e26a990d91f9dff.
A.3. Example 3: Security Blocks from Multiple Sources
This example shows the addition of a BIB and BCB to a sample bundle.
These two security blocks are added by two different nodes. The BCB
is added by the source endpoint and the BIB is added by a forwarding
node.
The resulting bundle contains a BCB to encrypt the Payload Block and
a BIB to provide integrity to the Primary and Bundle Age Block.
A.3.1. Original Bundle
The following diagram shows the original bundle before the security
blocks have been added.
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Extension Block: Bundle Age Block | 7 | 2 |
+----------------------------------------+-------+--------+
| Payload Block | 0 | 1 |
+----------------------------------------+-------+--------+
Figure 12: Example 3 Original Bundle
A.3.1.1. Primary Block
The primary block used in this example is identical to the primary
block presented in Example 1 Appendix A.1.1.1.
In summary, the CBOR encoding of the primary block is
0x88070000820282010282028202018202820201820018281a000f4240.
A.3.1.2. Bundle Age Block
A bundle age block is added to the bundle to help other nodes in the
network determine the age of the bundle. The use of this block is as
recommended because the bundle source does not have an accurate clock
(as indicated by the DTN time of 0).
Because this block is specified at the time the bundle is being
forwarded, the bundle age represents the time that has elapsed from
the time the bundle was created to the time it is being prepared for
forwarding. In this case, the value is given as 300 milliseconds.
The bundle age extension block is provided as follows.
[
7, / type code: Bundle Age block /
2, / block number /
0, / block processing flags /
0, / CRC Type /
<<300>> / type-specific-data: age /
]
Figure 13: Bundle Age Block (CDDL)
The CBOR encoding of the bundle age block is 0x85070200004319012c.
A.3.1.3. Payload Block
The payload block used in this example is identical to the payload
block presented in Example 1 Appendix A.1.1.2.
In summary, the CBOR encoding of the payload block is 0x8501010000582
052656164792047656e657261746520612033322062797465207061796c6f6164.
A.3.1.4. Bundle CBOR Representation
A BPv7 bundle is represented as an indefinite-length array consisting
of the blocks comprising the bundle, with a terminator character at
the end.
The CBOR encoding of the original bundle is 0x9f880700008202820102820
28202018202820201820018281a000f424085070200004319012c8501010000582052
656164792047656e657261746520612033322062797465207061796c6f6164ff.
A.3.2. Security Operation Overview
This example provides:
a BIB with the BIB-HMAC-SHA2 security context to provide an
integrity mechanism over the primary block and bundle age block.
a BCB with the BCB-AES-GCM security context to provide a
confidentiality mechanism over the payload block.
The following diagram shows the resulting bundle after the security
blocks are added.
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Bundle Integrity Block | 11 | 3 |
| OP(bib-integrity, targets=0, 2) | | |
+----------------------------------------+-------+--------+
| Bundle Confidentiality Block | 12 | 4 |
| OP(bcb-confidentiality, target=1) | | |
+----------------------------------------+-------+--------+
| Extension Block: Bundle Age Block | 7 | 2 |
+----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 0 | 1 |
+----------------------------------------+-------+--------+
Figure 14: Example 3 Resulting Bundle
A.3.3. Bundle Integrity Block
In this example, a BIB is used to carry an integrity signature over
the bundle age block and an additional signature over the payload
block. The BIB is added by a waypoint node, ipn:3.0.
A.3.3.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters
are used to generate the security results indicated.
This BIB has two security targets and includes two security results,
holding the calculated signatures over the bundle age block and
primary block.
Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
SHA Variant: HMAC 256/256
Scope Flags: 0
Primary Block Data: h'8807000082028201028202820201820282020182001
8281a000f4240'
Bundle Age Block
Data: h'85070200004319012c'
Primary Block
Signature: h'2f74b42d88234f0a8a98a6c72775ec6511aff3cb5bf
c06aa648f5fc40f31ec0d'
Bundle Age Block
Signature: h'e61385353ce2b4cce5319bc33326cdc26f4061e76cb
21b434c89199a36b00de3'
Figure 15: Example 3: Configuration, Parameters, and Results for the
BIB
A.3.3.2. Abstract Security Block
The abstract security block structure of the BIB's block-type-
specific-data field for this application is as follows.
[0, 2], / Security Target /
1, / Security Context ID - BIB-HMAC-SHA2 /
1, / Security Context Flags - Parameters Present /
[2,[3, 0]], / Security Source - ipn:3.0 /
[ / Security Parameters - 2 Parameters /
[1, 5], / SHA Variant - HMAC 256/256 /
[3, 0] / Scope Flags - No Additional Scope /
],
[ / Security Results: 2 Results /
[1, h'2f74b42d88234f0a8a98a6c72775ec6511aff3 / Primary Block /
cb5bfc06aa648f5fc40f31ec0d'],
[1, h'e61385353ce2b4cce5319bc33326cdc26f4061 / Bundle Age Block /
e76cb21b434c89199a36b00de3']
]
Figure 16: Example 3: BIB Abstract Security Block (CDDL)
The CBOR encoding of the BIB block-type-specific-data field (the
abstract security block) is 0x820002010182028203008282010582030082820
158202f74b42d88234f0a8a98a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d
82015820e61385353ce2b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00
de3.
A.3.3.3. Representations
The BIB wrapping this abstract security block is as follows.
[
11, / type code /
3, / block number /
0, / flags /
0, / CRC type /
h'820002010182028203008282010582030082820158202f74b42d88234f0a8a98
a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d82015820e61385353ce2
b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00de3',
]
Figure 17: Example 3: BIB (CDDL)
The CBOR encoding of the BIB block is 0x850b030000585a820002010182028
203008282010582030082820158202f74b42d88234f0a8a98a6c72775ec6511aff3cb
5bfc06aa648f5fc40f31ec0d82015820e61385353ce2b4cce5319bc33326cdc26f406
1e76cb21b434c89199a36b00de3.
A.3.4. Bundle Confidentiality Block
In this example, a BCB is used encrypt the payload block. The BCB is
added by the bundle source node, ipn:2.1.
A.3.4.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters
are used to generate the security results indicated.
This BCB has a single target, the payload block. Two security
results are generated: cipher text which replaces the plain text
block-type-specific data to encrypt the payload block, and an
authentication tag.
Content Encryption
Key: h'71776572747975696f70617364666768'
IV: h'5477656c7665313231323132'
AES Variant: A128GCM
Scope Flags: 0
Payload Data: h'52656164792047656e65726174652061
2033322062797465207061796c6f6164'
Authentication Tag: h'689b98e649ae3b554e98aa2ae8f801eb'
Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354
a563e32648b700c2784e26a990d91f9d'
Figure 18: Example 3: Configuration, Parameters, and Results for the
BCB
A.3.4.2. Abstract Security Block
The abstract security block structure of the BCB's block-type-
specific-data field for this application is as follows.
[1], / Security Target /
2, / Security Context ID - BCB-AES-GCM /
1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 3 Parameters /
[1, b'Twelve121212'] / Initialization Vector /,
[2, 1] / AES Variant - AES 128 /,
[4, 0] / Scope Flags - No Additional Scope /
],
[ / Security Results: 1 Result /
[1, h'689b98e649ae3b554e98aa2ae8f801eb'] / Payload Auth. Tag /
]
Figure 19: Example 3: BCB Abstract Security Block (CDDL)
The CBOR encoding of the BCB block-type-specific-data field (the
abstract security block) is 0x8101020182028202018382014c5477656C76653
1323132313282020182040081820150689b98e649ae3b554e98aa2ae8f801eb.
A.3.4.3. Representations
The BCB wrapping this abstract security block is as follows.
[
12, / type code /
4, / block number /
1, / flags - block must be replicated in every fragment /
0, / CRC type /
h'8101020182028202018382014c5477656C766531323132313282020182040081
820150689b98e649ae3b554e98aa2ae8f801eb',
]
Figure 20: Example 3: BCB (CDDL)
The CBOR encoding of the BCB block is 0x850c0401005833810102018202820
2018382014c5477656C766531323132313282020182040081820150689b98e649ae3b
554e98aa2ae8f801eb.
A.3.5. Final Bundle
The CBOR encoding of the full output bundle, with the BIB and BCB
added is: 9F88070000820282010282028202018202820201820018281a000f42408
50b030000585a820002010182028203008282010582030082820158202f74b42d8823
4f0a8a98a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d82015820e61385353
ce2b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00de3850c0401005833
8101020182028202018382014c5477656C76653132313231328202018204008182015
0689b98e649ae3b554e98aa2ae8f801eb85070200004319012c850101000058203a09
c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dFF.
A.4. Example 4: Security Blocks with Full Scope
This example shows the addition of a BIB and BCB to a sample bundle.
A BIB is added to provide integrity over the payload block and a BCB
is added for confidentiality over the payload and BIB.
The integrity scope and additional authentication data will bind the
primary block, target header, and the security header.
A.4.1. Original Bundle
The following diagram shows the original bundle before the security
blocks have been added.
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Payload Block | 0 | 1 |
+----------------------------------------+-------+--------+
Figure 21: Example 4 Original Bundle
A.4.1.1. Primary Block
The primary block used in this example is identical to the primary
block presented in Example 1 Appendix A.1.1.1.
In summary, the CBOR encoding of the primary block is
0x88070000820282010282028202018202820201820018281a000f4240.
A.4.1.2. Payload Block
The payload block used in this example is identical to the payload
block presented in Example 1 Appendix A.1.1.2.
In summary, the CBOR encoding of the payload block is 0x8501010000582
052656164792047656e657261746520612033322062797465207061796c6f6164.
A.4.1.3. Bundle CBOR Representation
A BPv7 bundle is represented as an indefinite-length array consisting
of the blocks comprising the bundle, with a terminator character at
the end.
The CBOR encoding of the original bundle is 0x9f880700008202820102820
28202018202820201820018281a000f42408501010000582052656164792047656e65
7261746520612033322062797465207061796c6f6164ff.
A.4.2. Security Operation Overview
This example provides:
a BIB with the BIB-HMAC-SHA2 security context to provide an
integrity mechanism over the payload block.
a BCB with the BCB-AES-GCM security context to provide a
confidentiality mechanism over the payload block and BIB.
The following diagram shows the resulting bundle after the security
blocks are added.
Block Block Block
in Bundle Type Number
+========================================+=======+========+
| Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+
| Bundle Integrity Block (Encrypted) | 11 | 3 |
| OP(bib-integrity, target=1) | | |
+----------------------------------------+-------+--------+
| Bundle Confidentiality Block | 12 | 4 |
| OP(bcb-confidentiality, targets=1, 3) | | |
+----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 0 | 1 |
+----------------------------------------+-------+--------+
Figure 22: Example 4 Resulting Bundle
A.4.3. Bundle Integrity Block
In this example, a BIB is used to carry an integrity signature over
the payload block. The IPPT contains the payload block block-type-
specific data, primary block data, the payload block header, and the
BIB header. That is, all additional headers are included in the
IPPT.
A.4.3.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters
are used to generate the security results indicated.
This BIB has a single target and includes a single security result:
the calculated signature over the Payload block.
Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
SHA Variant: HMAC 384/384
Scope Flags: 7 (all additional headers)
Primary Block Data: h'88070000820282010282028202018202
820201820018281a000f4240
Payload Data: h'52656164792047656e65726174652061
2033322062797465207061796c6f6164'
Payload Header: h'85010100005820'
BIB Header: h'850b0300005845'
Payload Signature: h'6f56e0f58ec584df34603c75cc055939
00b1a938f23883f119772e1230441d86
9bce6ac9559f721260314424ab14b981
Figure 23: Example 4: Configuration, Parameters, and Results for the
BIB
A.4.3.2. Abstract Security Block
The abstract security block structure of the BIB's block-type-
specific-data field for this application is as follows.
[1], / Security Target /
1, / Security Context ID - BIB-HMAC-SHA2 /
1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source: ipn:2.1 /
[ / Security Parameters: 2 Parameters /
[1, 6], / SHA Variant - HMAC 384/384 /
[3, 7] / Scope Flags - All additional headers in the SHA Hash /
],
[ / Security Results: 1 Result /
[1, h'6f56e0f58ec584df34603c75cc05593900b1a938f23883f119772e123044
1d869bce6ac9559f721260314424ab14b981']
]
Figure 24: Example 4: BIB Abstract Security Block (CDDL)
The CBOR encoding of the BIB block-type-specific-data field (the
abstract security block) is 0x810101018202820201828201068203078182015
8306f56e0f58ec584df34603c75cc05593900b1a938f23883f119772e1230441d869b
ce6ac9559f721260314424ab14b981.
A.4.3.3. Representations
The BIB wrapping this abstract security block is as follows.
[
11, / type code /
3, / block number /
0, / flags /
0, / CRC type /
h'8101010182028202018282010682030781820158306f56e0f58ec584df34603c
75cc05593900b1a938f23883f119772e1230441d869bce6ac9559f7212603144
24ab14b981',
]
Figure 25: Example 4: BIB (CDDL)
The CBOR encoding of the BIB block is 0x850b0300005845810101018202820
2018282010682030781820158306f56e0f58ec584df34603c75cc05593900b1a938f2
3883f119772e1230441d869bce6ac9559f721260314424ab14b981.
A.4.4. Bundle Confidentiality Block
In this example, a BCB is used encrypt the payload block and the BIB
that provides integrity over the payload.
A.4.4.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters
are used to generate the security results indicated.
This BCB has two targets: the payload block and BIB. Four security
results are generated: cipher text which replaces the plain text
block-type-specific data of the payload block, cipher text to encrypt
the BIB, and authentication tags for both the payload block and BIB.
Key: h'71776572747975696f70617364666768
71776572747975696f70617364666768'
IV: h'5477656c7665313231323132'
AES Variant: A256GCM
Scope Flags: 7 (All additional headers)
Payload Data: h'52656164792047656e65726174652061
2033322062797465207061796c6f6164'
BIB Data: h'52656164792047656E65726174652061
2033322062797465207061796C6F6164'
BIB
Authentication Tag: h'92bc2665e9f04350c5974f023929dd62'
Payload Block
Authentication Tag: h'865bc14b3910d6c53e95fdc65aa601fd'
Payload Ciphertext: h'90eab64575930498d6aa654107f15e96
319bb227706000abc8fcac3b9bb9c87e'
BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0
902a815f2276222e1d0208c628e2c926
2a0c438fc300190dbf5954ae4f84f748
64e58ed1e39043633142ad2559e0e3a9
c9cbce5c2d'
Figure 26: Example 4: Configuration, Parameters, and Results for the
BCB
A.4.4.2. Abstract Security Block
The abstract security block structure of the BCB's block-type-
specific-data field for this application is as follows.
[3, 1], / Security Target /
2, / Security Context ID - BCB-AES-GCM /
1, / Security Context Flags - Parameters Present /
[2,[2, 1]], / Security Source - ipn:2.1 /
[ / Security Parameters - 3 Parameters /
[1, h'5477656c7665313231323132'] / Initialization Vector /,
[2, 3] / AES Variant - AES 256 /,
[4, 7] / Scope Flags - All headers in SHA hash /
],
[ / Security Results: 2 Results /
[1, h'865bc14b3910d6c53e95fdc65aa601fd'], / Payload Auth. Tag /
[1, h'92bc2665e9f04350c5974f023929dd62'] / BIB Auth. Tag /
]
Figure 27: Example 4: BCB Abstract Security Block (CDDL)
The CBOR encoding of the BCB block-type-specific-data field (the
abstract security block) is 0x820301020182028202018382014c5477656C766
531323132313282020382040782820150d0b506cc2e5ede57b36e6c52791457008201
50865bc14b3910d6c53e95fdc65aa601fd.
A.4.4.3. Representations
The BCB wrapping this abstract security block is as follows.
[
12, / type code /
2, / block number /
1, / flags - block must be replicated in every fragment /
0, / CRC type /
h'820301020182028202018382014c5477656C7665313231323132820203820407
82820150d0b506cc2e5ede57b36e6c5279145700820150865bc14b3910d6c53e
95fdc65aa601fd',
]
Figure 28: Example 4: BCB (CDDL)
The CBOR encoding of the BCB block is 0x850c0201005847820301020182028
202018382014c5477656C766531323132313282020382040782820150d0b506cc2e5e
de57b36e6c5279145700820150865bc14b3910d6c53e95fdc65aa601fd.
A.4.5. Final Bundle
The CBOR encoding of the full output bundle, with the security blocks
added and payload block and BIB encrypted is: 9F880700008202820102820
28202018202820201820018281a000f4240850b0300005845438ed6208eb1c1ffb94d
952175167df0902a815f2276222e1d0208c628e2c9262a0c438fc300190dbf5954ae4
f84f74864e58ed1e39043633142ad2559e0e3a9c9cbce5c2d 850c020100584782030
1020182028202018382014c5477656C766531323132313282020382040782820150d0
b506cc2e5ede57b36e6c5279145700820150865bc14b3910d6c53e95fdc65aa601fd8
501010000582090eab64575930498d6aa654107f15e96319bb227706000abc8fcac3b
9bb9c87eFF.
Appendix B. Acknowledgements
The following participants contributed useful review and analysis of The following participants contributed useful review and analysis of
these security contexts: Amy Alford and Sarah Heiner of the Johns these security contexts: Amy Alford of the Johns Hopkins University
Hopkins University Applied Physics Laboratory. Applied Physics Laboratory.
Author's Address Authors' Addresses
Edward J. Birrane, III Edward J. Birrane, III
The Johns Hopkins University Applied The Johns Hopkins University Applied
Physics Laboratory Physics Laboratory
11100 Johns Hopkins Rd. 11100 Johns Hopkins Rd.
Laurel, MD 20723 Laurel, MD 20723
US US
Phone: +1 443 778 7423 Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu Email: Edward.Birrane@jhuapl.edu
Alex White
The Johns Hopkins University Applied
Physics Laboratory
11100 Johns Hopkins Rd.
Laurel, MD 20723
US
Phone: +1 443 778 0845
Email: Alex.White@jhuapl.edu
Sarah Heiner
The Johns Hopkins University Applied
Physics Laboratory
11100 Johns Hopkins Rd.
Laurel, MD 20723
US
Phone: +1 240 592 3704
Email: Sarah.Heiner@jhuapl.edu
 End of changes. 24 change blocks. 
49 lines changed or deleted 1038 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/