draft-ietf-dtn-bpsec-default-sc-08.txt   draft-ietf-dtn-bpsec-default-sc-09.txt 
Delay-Tolerant Networking E. Birrane Delay-Tolerant Networking E. Birrane
Internet-Draft A. White Internet-Draft A. White
Intended status: Standards Track S. Heiner Intended status: Standards Track S. Heiner
Expires: December 10, 2021 JHU/APL Expires: January 9, 2022 JHU/APL
June 8, 2021 July 8, 2021
BPSec Default Security Contexts BPSec Default Security Contexts
draft-ietf-dtn-bpsec-default-sc-08 draft-ietf-dtn-bpsec-default-sc-09
Abstract Abstract
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 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 36 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 December 10, 2021. This Internet-Draft will expire on January 9, 2022.
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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Integrity Security Context BIB-HMAC-SHA2 . . . . . . . . . . 4 3. Integrity Security Context BIB-HMAC-SHA2 . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. SHA Variant . . . . . . . . . . . . . . . . . . . . . 6 3.3.1. SHA Variant . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 7
3.3.3. Integrity Scope Flags . . . . . . . . . . . . . . . . 7 3.3.3. Integrity Scope Flags . . . . . . . . . . . . . . . . 8
3.3.4. Enumerations . . . . . . . . . . . . . . . . . . . . 8 3.3.4. Enumerations . . . . . . . . . . . . . . . . . . . . 8
3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Key Considerations . . . . . . . . . . . . . . . . . . . 9 3.5. Key Considerations . . . . . . . . . . . . . . . . . . . 9
3.6. Canonicalization Algorithms . . . . . . . . . . . . . . . 9 3.6. Security Processing Considerations . . . . . . . . . . . 10
3.7. Processing . . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 10
3.7.1. Keyed Hash Generation . . . . . . . . . . . . . . . . 10 3.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 11
3.7.2. Keyed Hash Verification . . . . . . . . . . . . . . . 11 3.8.1. Keyed Hash Generation . . . . . . . . . . . . . . . . 11
4. Security Context BCB-AES-GCM . . . . . . . . . . . . . . . . 12 3.8.2. Keyed Hash Verification . . . . . . . . . . . . . . . 12
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Security Context BCB-AES-GCM . . . . . . . . . . . . . . . . 13
4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 15 4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 15 4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 16
4.3.3. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 16 4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 16
4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 16 4.3.3. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 17
4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 17 4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 17
4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 18
4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 18 4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 18 4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 19
4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 18 4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 19
4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 19 4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 20
4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 20 4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 21
4.7.1. Cipher text related calculations . . . . . . . . . . 20 4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 22
4.7.2. Additional Authenticated Data . . . . . . . . . . . . 21 4.7.1. Cipher text related calculations . . . . . . . . . . 22
4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 21 4.7.2. Additional Authenticated Data . . . . . . . . . . . . 23
4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 21 4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 23
4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 23 4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 23
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 25
5.1. Security Context Identifiers . . . . . . . . . . . . . . 24 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
5.2. Integrity Scope Flags . . . . . . . . . . . . . . . . . . 25 5.1. Security Context Identifiers . . . . . . . . . . . . . . 26
5.3. AAD Scope Flags . . . . . . . . . . . . . . . . . . . . . 25 5.2. Integrity Scope Flags . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5.3. AAD Scope Flags . . . . . . . . . . . . . . . . . . . . . 27
6.1. Key Management . . . . . . . . . . . . . . . . . . . . . 26 5.4. Guidance for Designated Experts . . . . . . . . . . . . . 28
6.2. Key Handling . . . . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.3. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1. Key Management . . . . . . . . . . . . . . . . . . . . . 29
6.4. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 28 6.2. Key Handling . . . . . . . . . . . . . . . . . . . . . . 30
6.5. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 29 6.3. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Normative References . . . . . . . . . . . . . . . . . . . . 29 6.4. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 30 6.5. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 32
A.1. Example 1: Simple Integrity . . . . . . . . . . . . . . . 31 7. Normative References . . . . . . . . . . . . . . . . . . . . 32
A.1.1. Original Bundle . . . . . . . . . . . . . . . . . . . 31 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 34
A.1.2. Security Operation Overview . . . . . . . . . . . . . 33 A.1. Example 1: Simple Integrity . . . . . . . . . . . . . . . 34
A.1.3. Bundle Integrity Block . . . . . . . . . . . . . . . 34 A.1.1. Original Bundle . . . . . . . . . . . . . . . . . . . 34
A.1.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 35 A.1.2. Security Operation Overview . . . . . . . . . . . . . 36
A.2. Example 2: Simple Confidentiality with Key Wrap . . . . . 35 A.1.3. Bundle Integrity Block . . . . . . . . . . . . . . . 37
A.2.1. Original Bundle . . . . . . . . . . . . . . . . . . . 35 A.1.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 38
A.2.2. Security Operation Overview . . . . . . . . . . . . . 36 A.2. Example 2: Simple Confidentiality with Key Wrap . . . . . 39
A.2.3. Bundle Confidentiality Block . . . . . . . . . . . . 37 A.2.1. Original Bundle . . . . . . . . . . . . . . . . . . . 39
A.2.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 39 A.2.2. Security Operation Overview . . . . . . . . . . . . . 40
A.3. Example 3: Security Blocks from Multiple Sources . . . . 39 A.2.3. Bundle Confidentiality Block . . . . . . . . . . . . 40
A.3.1. Original Bundle . . . . . . . . . . . . . . . . . . . 39 A.2.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 42
A.3.2. Security Operation Overview . . . . . . . . . . . . . 41 A.3. Example 3: Security Blocks from Multiple Sources . . . . 42
A.3.3. Bundle Integrity Block . . . . . . . . . . . . . . . 41 A.3.1. Original Bundle . . . . . . . . . . . . . . . . . . . 42
A.3.4. Bundle Confidentiality Block . . . . . . . . . . . . 43 A.3.2. Security Operation Overview . . . . . . . . . . . . . 44
A.3.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 45 A.3.3. Bundle Integrity Block . . . . . . . . . . . . . . . 45
A.4. Example 4: Security Blocks with Full Scope . . . . . . . 45 A.3.4. Bundle Confidentiality Block . . . . . . . . . . . . 47
A.4.1. Original Bundle . . . . . . . . . . . . . . . . . . . 45 A.3.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 48
A.4.2. Security Operation Overview . . . . . . . . . . . . . 46 A.4. Example 4: Security Blocks with Full Scope . . . . . . . 49
A.4.3. Bundle Integrity Block . . . . . . . . . . . . . . . 47 A.4.1. Original Bundle . . . . . . . . . . . . . . . . . . . 49
A.4.4. Bundle Confidentiality Block . . . . . . . . . . . . 49 A.4.2. Security Operation Overview . . . . . . . . . . . . . 50
A.4.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 50 A.4.3. Bundle Integrity Block . . . . . . . . . . . . . . . 50
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 51 A.4.4. Bundle Confidentiality Block . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 A.4.5. Final Bundle . . . . . . . . . . . . . . . . . . . . 54
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
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.
This document defines two security contexts (one for an integrity This document defines two security contexts (one for an integrity
service and one for a confidentiality service) for populating BPSec service and one for a confidentiality service) for populating BPSec
Block Integrity Blocks (BIBs) and Block Confidentiality Blocks Block Integrity Blocks (BIBs) and Block Confidentiality Blocks
(BCBs). (BCBs). This document assumes familiarity with the concepts and
terminology associated with BP and BPSec, as these security contexts
are used with BPSec security blocks and other BP blocks carried
within BP bundles.
These contexts generate information that MUST be encoded using the These contexts generate information that MUST be encoded using the
CBOR specification documented in [RFC8949]. CBOR specification documented in [RFC8949].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Integrity Security Context BIB-HMAC-SHA2 3. Integrity Security Context BIB-HMAC-SHA2
3.1. Overview 3.1. Overview
The BIB-HMAC-SHA2 security context provides a keyed hash over a set The BIB-HMAC-SHA2 security context provides a keyed-hash Message
of plain text information. This context uses the Secure Hash Authentication Code (MAC) over a set of plain text information. This
Algorithm 2 (SHA-2) discussed in [SHS] combined with the HMAC keyed context uses the Secure Hash Algorithm 2 (SHA-2) discussed in [SHS]
hash discussed in [HMAC]. The combination of HMAC and SHA-2 as the combined with the HMAC keyed hash discussed in [RFC2104]. The
integrity mechanism for this security context was selected for two combination of HMAC and SHA-2 as the integrity mechanism for this
reasons: security context was selected for two reasons:
1. The use of symmetric keys allows this security context to be used 1. The use of symmetric keys allows this security context to be used
in places where an asymmetric-key infrastructure (such as a in places where an asymmetric-key infrastructure (such as a
public key infrastructure) might be impractical. public key infrastructure) might be impractical.
2. The combination HMAC-SHA2 represents a well-supported and well- 2. The combination HMAC-SHA2 represents a well-supported and well-
understood integrity mechanism with multiple implementations understood integrity mechanism with multiple implementations
available. available.
BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the
skipping to change at page 5, line 4 skipping to change at page 5, line 12
The BIB-HMAC-SHA2 security context MUST have the security context The BIB-HMAC-SHA2 security context MUST have the security context
identifier specified in Section 5.1. identifier specified in Section 5.1.
3.2. Scope 3.2. Scope
The scope of BIB-HMAC-SHA2 is the set of information used to produce The scope of BIB-HMAC-SHA2 is the set of information used to produce
the plain text over which a keyed hash is calculated. This plain the plain text over which a keyed hash is calculated. This plain
text is termed the "Integrity Protected Plain Text" (IPPT). The text is termed the "Integrity Protected Plain Text" (IPPT). The
content of the IPPT is constructed as the concatenation of content of the IPPT is constructed as the concatenation of
information whose integrity is being preserved from the BIB-HMAC-SHA2 information whose integrity is being preserved from the BIB-HMAC-SHA2
security source to its security acceptor. There are four types of security source to its security acceptor. There are five types of
information that can be used in the generation of the IPPT, based on information that can be used in the generation of the IPPT, based on
how broadly the concept of integrity is being applied. These four how broadly the concept of integrity is being applied. These five
types of information, whether they are required, and why they are types of information, whether they are required, and why they are
important for integrity, are discussed as follows. important for integrity, are discussed as follows.
Security target contents Security target contents
The contents of the block-type-specific data field of the The contents of the block-type-specific data field of the
security target MUST be included in the IPPT. Including this security target MUST be included in the IPPT. Including this
information protects the security target data and is considered information protects the security target data and is considered
the minimal, required set of information for an integrity service the minimal, required set of information for an integrity service
on the security target. on the security target.
IPPT Scope
The determination of which optional types of information were
used when constructing the IPPT MUST, itself, always be included
in the IPPT. Including this information ensures that the scope
of the IPPT construction at a security source matches the scope
of the IPPT construction at security verifiers and security
acceptors.
Primary block Primary block
The primary block identifies a bundle and, once created, the The primary block identifies a bundle and, once created, the
contents of this block are immutable. Changes to the primary contents of this block are immutable. Changes to the primary
block associated with the security target indicate that the block associated with the security target indicate that the
security target (and BIB) might no longer be in the correct security target (and BIB) might no longer be in the correct
bundle. bundle.
For example, if a security target and associated BIB are copied For example, if a security target and associated BIB are copied
from one bundle to another bundle, the BIB might still contain a from one bundle to another bundle, the BIB might still contain a
verifiable signature for the security target unless information verifiable signature for the security target unless information
skipping to change at page 6, line 22 skipping to change at page 6, line 36
Including this information in the IPPT protects the integrity of Including this information in the IPPT protects the integrity of
the policy and identification of the security service in the the policy and identification of the security service in the
bundle. bundle.
NOTE: The security context identifier and security context NOTE: The security context identifier and security context
parameters of the security block are not included in the IPPT parameters of the security block are not included in the IPPT
because these parameters, by definition, are required to verify because these parameters, by definition, are required to verify
or accept the security service. Successful verification at or accept the security service. Successful verification at
security verifiers and security acceptors implies that these security verifiers and security acceptors implies that these
parameters were unchanged since being specified at the security parameters were unchanged since being specified at the security
source. source. This is the case because keys cannot be re-used across
security contexts, and because the integrity scope flags used to
define the IPPT are included in the IPPT itself.
The scope of the BIB-HMAC-SHA2 security context is configured using The scope of the BIB-HMAC-SHA2 security context is configured using
an optional security context parameter. an optional security context parameter.
3.3. Parameters 3.3. Parameters
BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants,
communicate key information, and define the scope of the IPPT. communicate key information, and define the scope of the IPPT.
3.3.1. SHA Variant 3.3.1. SHA Variant
skipping to change at page 7, line 28 skipping to change at page 7, line 37
Table 1 Table 1
When not provided, implementations SHOULD assume a value of 6 When not provided, implementations SHOULD assume a value of 6
(indicating use of HMAC 384/384), unless an alternate default is (indicating use of HMAC 384/384), unless an alternate default is
established by local security policy at the security source, established by local security policy at the security source,
verifiers, or acceptor of this integrity service. verifiers, or acceptor of this integrity service.
3.3.2. Wrapped Key 3.3.2. Wrapped Key
This optional parameter contains the output of the AES key wrap This optional parameter contains the output of the AES key wrap
authenticated encryption function (KW-AE) as defined in [AES-KW]. authenticated encryption function (KW-AE) as defined in [RFC5649].
Specifically, this parameter holds the cipher text produced when Specifically, this parameter holds the cipher text produced when
running the KW-AE algorithm with the input string being the symmetric running the KW-AE algorithm with the input string being the symmetric
HMAC key used to generate the security results present in the HMAC key used to generate the security results present in the
security block. The value of this parameter is used as input to the security block. The value of this parameter is used as input to the
AES key wrap authenticated decryption function (KW-AD) at security AES key wrap authenticated decryption function (KW-AD) at security
verifiers and security acceptors to determine the symmetric HMAC key verifiers and security acceptors to determine the symmetric HMAC key
needed for the proper validation of the security results in the needed for the proper validation of the security results in the
security block. security block.
This value MUST be encoded as a CBOR byte string. This value MUST be encoded as a CBOR byte string.
skipping to change at page 8, line 10 skipping to change at page 8, line 19
constructing the IPPT value. constructing the IPPT value.
This value MUST be represented as a CBOR unsigned integer, the value This value MUST be represented as a CBOR unsigned integer, the value
of which MUST be processed as a bit field. of which MUST be processed as a bit field.
Integrity scope flags that are unrecognized MUST be ignored, as Integrity scope flags that are unrecognized MUST be ignored, as
future definitions of additional flags might not be integrated future definitions of additional flags might not be integrated
simultaneously into security context implementations operating at all simultaneously into security context implementations operating at all
nodes. nodes.
Implementations MUST set reserved and unassigned bits in this field
to 0 when constructing these flags at a security source. Once set,
the value of this field MUST NOT be altered until the security
service is completed at the security acceptor in the network and
removed from the bundle.
Bits in this field represent additional information to be included Bits in this field represent additional information to be included
when generating an integrity signature over the security target. when generating an integrity signature over the security target.
These bits are defined as follows. These bits are defined as follows.
- Bit 0 (the low-order bit, 0x0001): Primary Block Flag. - Bit 0 (the low-order bit, 0x0001): Primary Block Flag.
- Bit 1 (0x0002): Target Header Flag. - Bit 1 (0x0002): Target Header Flag.
- Bit 2 (0x0003): Security Header Flag. - Bit 2 (0x0004): Security Header Flag.
- Bits 3-7 are reserved. - Bits 3-7 are reserved.
- Bits 8-15 are unassigned. - Bits 8-15 are unassigned.
3.3.4. Enumerations 3.3.4. Enumerations
BIB-HMAC-SHA2 defines the following security context parameters. The BIB-HMAC-SHA2 security context parameters are listed in Table 2.
In this table, the "Parm Id" column refers to the expected Parameter
Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter
and Result Identification".
If the default value column is empty, this indicates that the
security parameter does not have a default value.
BIB-HMAC-SHA2 Security Parameters BIB-HMAC-SHA2 Security Parameters
+----+-----------------------+--------------------+---------------+ +---------+---------------------+-------------------+---------------+
| Id | Name | CBOR Encoding Type | Default Value | | Parm Id | Parm Name | CBOR Encoding | Default Value |
+----+-----------------------+--------------------+---------------+ | | | Type | |
| 1 | SHA Variant | UINT | 6 | +---------+---------------------+-------------------+---------------+
| 2 | Wrapped Key | Byte String | NONE | | 1 | SHA Variant | unsigned integer | 6 |
| 4 | Integrity Scope Flags | UINT | 0x7 | | 2 | Wrapped Key | Byte String | |
+----+-----------------------+--------------------+---------------+ | 3 | Integrity Scope | unsigned integer | 7 |
| | Flags | | |
+---------+---------------------+-------------------+---------------+
Table 2 Table 2
3.4. Results 3.4. Results
BIB-HMAC-SHA2 defines the following security results. The BIB-HMAC-SHA2 security context results are listed in Table 3. In
this table, the "Result Id" column refers to the expected Result
Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter
and Result Identification".
BIB-HMAC-SHA2 Security Results BIB-HMAC-SHA2 Security Results
+--------+----------+-------------+---------------------------------+ +--------+----------+-------------+---------------------------------+
| Result | Result | CBOR | Description | | Result | Result | CBOR | Description |
| Id | Name | Encoding | | | Id | Name | Encoding | |
| | | Type | | | | | Type | |
+--------+----------+-------------+---------------------------------+ +--------+----------+-------------+---------------------------------+
| 1 | Expected | byte string | The output of the HMAC | | 1 | Expected | byte string | The output of the HMAC |
| | HMAC | | calculation at the security | | | HMAC | | calculation at the security |
| | | | source. | | | | | source. |
+--------+----------+-------------+---------------------------------+ +--------+----------+-------------+---------------------------------+
Table 3 Table 3
3.5. Key Considerations 3.5. Key Considerations
HMAC keys used with this context MUST be symmetric and MUST have a HMAC keys used with this context MUST be symmetric and MUST have a
key length equal to the output of the HMAC. For this reason, HMAC key length equal to the output of the HMAC. For this reason, HMAC
keys will be integer divisible by 8 bytes and special padding-aware key lengths will be integer divisible by 8 bytes and special padding-
AES key wrap algorithms are not needed. aware AES key wrap algorithms are not needed.
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:
Pre-placed keys selected based on local policy. Pre-placed keys selected based on local policy.
Keys extracted from material carried in the BIB. Keys extracted from material carried in the BIB.
skipping to change at page 9, line 46 skipping to change at page 10, line 18
When an AES-KW wrapped key is present in a security block, it is When an AES-KW wrapped key is present in a security block, it is
assumed that security verifiers and security acceptors can assumed that security verifiers and security acceptors can
independently determine the key encryption key (KEK) used in the independently determine the key encryption key (KEK) used in the
wrapping of the symmetric HMAC key. wrapping of the symmetric HMAC key.
As discussed in Section 6 and emphasized here, it is strongly As discussed in Section 6 and emphasized here, it is strongly
recommended that keys be protected once generated, both when they are recommended that keys be protected once generated, both when they are
stored and when they are transmitted. stored and when they are transmitted.
3.6. Canonicalization Algorithms 3.6. Security Processing Considerations
An HMAC calculated over the same IPPT with the same key will always
have the same value. This regularity can lead to practical side-
channel attacks whereby an attacker could produce known plain text
and a guess at an HMAC tag and observe the behavior of a verifier.
With a modest number of trials, a side-channel attack could produce
an HMAC tag for attacher-provided plain text without the attacker
ever knowing the HMAC key.
A common method of observing the behavior of a verifier is precise
analysis of the timing associated with comparisons. Therefore, one
way to prevent behavior analysis of this type is to ensure that any
comparisons of the supplied and expected authentication tag occur in
constant time.
A constant-time comparison function SHOULD be used for the comparison
of authentication tags by any implementation of this security
context. In cases where such a function is difficult or impossible
to use, the impact of side-channel (in general) and timing attacks
(specifically) need to be considered as part of the implementation.
3.7. Canonicalization Algorithms
This section defines the canonicalization algorithm used to prepare This section defines the canonicalization algorithm used to prepare
the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The
construction of the IPPT depends on the settings of the integrity construction of the IPPT depends on the settings of the integrity
scope flags that can be provided as part of customizing the behavior scope flags that can be provided as part of customizing the behavior
of this security context. of this security context.
In all cases, the canonical form of any portion of an extension block In all cases, the canonical form of any portion of an extension block
MUST be performed as described in [I-D.ietf-dtn-bpsec]. The MUST be performed as described in [I-D.ietf-dtn-bpsec]. The
canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to
skipping to change at page 10, line 9 skipping to change at page 11, line 4
This section defines the canonicalization algorithm used to prepare This section defines the canonicalization algorithm used to prepare
the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The
construction of the IPPT depends on the settings of the integrity construction of the IPPT depends on the settings of the integrity
scope flags that can be provided as part of customizing the behavior scope flags that can be provided as part of customizing the behavior
of this security context. of this security context.
In all cases, the canonical form of any portion of an extension block In all cases, the canonical form of any portion of an extension block
MUST be performed as described in [I-D.ietf-dtn-bpsec]. The MUST be performed as described in [I-D.ietf-dtn-bpsec]. The
canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to
the canonical forms for extension blocks defined in the canonical forms for extension blocks defined in
[I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values
are represented in CBOR. are represented in CBOR.
The IPPT is constructed using the following process. The IPPT is constructed using the following process. While integrity
scope flags might not be included in the BIB representing the
security operation, they MUST be included in the IPPT value itself.
1. The canonical form of the IPPT starts as the empty set with 1. The canonical form of the IPPT starts as the CBOR encoding of the
length 0. integrity scope flags in which all unset flags, reserved bits,
and unassigned bits have been set to 0. For example, if the
primary block flag, target header flag, and security header flag
are each set, then the initial value of the canonical form of the
IPPT will be 0x07.
2. If the integrity scope parameter is present and the primary block 2. If the primary block flag of the integrity scope flags is set to
flag 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
block MUST be calculated and the result appended to the IPPT. calculated and the result appended to the IPPT.
3. If the integrity scope parameter is present and the target header 3. If the target header flag of the integrity scope flags is set to
flag 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,
block number, and block processing control flags associated with and block processing control flags associated with the security
the security target MUST be calculated and, in that order, target MUST be calculated and, in that order, appended to the
appended to the IPPT. IPPT.
4. If the integrity scope parameter is present and the security 4. If the security header flag of the integrity scope flags is set
header flag is set to 1, then the canonical form of the block to 1, then the canonical form of the block type code, block
type code, block number, and block processing control flags number, and block processing control flags associated with the
associated with the BIB MUST be calculated and, in that order, BIB MUST be calculated and, in that order, appended to the IPPT.
appended to the IPPT.
5. The canonical form of the security target block-type-specific 5. The canonical form of the security target block-type-specific
data MUST be calculated and appended to the IPPT. data MUST be calculated and appended to the IPPT.
3.7. Processing 3.8. Processing
3.7.1. Keyed Hash Generation 3.8.1. Keyed Hash Generation
During keyed hash generation, two inputs are prepared for the the During keyed hash generation, two inputs are prepared for the the
appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These
data items MUST be generated as follows. data items MUST be generated as follows.
The HMAC key MUST have the appropriate length as required by local The HMAC key MUST have the appropriate length as required by local
security policy. The key can be generated specifically for this security policy. The key can be generated specifically for this
integrity service, given as part of local security policy, or integrity service, given as part of local security policy, or
through some other key management mechanism as discussed in through some other key management mechanism as discussed in
Section 3.5. Section 3.5.
Prior to the generation of the IPPT, if a CRC value is present for Prior to the generation of the IPPT, if a CRC value is present for
the target block of the BIB, then that CRC value MUST be removed the target block of the BIB, then that CRC value MUST be removed
from the target block. This involves both removing the CRC value from the target block. This involves both removing the CRC value
from the target block and setting the CRC Type field of the target from the target block and setting the CRC Type field of the target
block to "no CRC is present." block to "no CRC is present."
Once CRC information is removed, the IPPT MUST be generated as Once CRC information is removed, the IPPT MUST be generated as
discussed in Section 3.6. discussed in Section 3.7.
Upon successful hash generation the following actions MUST occur. Upon successful hash generation the following actions MUST occur.
The keyed hash produced by the HMAC/SHA2 variant MUST be added as The keyed hash produced by the HMAC/SHA2 variant MUST be added as
a security result for the BIB representing the security operation a security result for the BIB representing the security operation
on this security target, as discussed in Section 3.4). on this security target, as discussed in Section 3.4.
Finally, the BIB containing information about this security operation Finally, the BIB containing information about this security operation
MUST be updated as follows. These operations can occur in any order. MUST be updated as follows. These operations can occur in any order.
The security context identifier for the BIB MUST be set to the The security context identifier for the BIB MUST be set to the
context identifier for BIB-HMAC-SHA2. context identifier for BIB-HMAC-SHA2.
Any local flags used to generate the IPPT SHOULD be placed in the Any local flags used to generate the IPPT MUST be placed in the
integrity scope flags security parameter for the BIB unless these integrity scope flags security parameter for the BIB unless these
flags are expected to be correctly configured at security flags are expected to be correctly configured at security
verifiers and acceptors in the network. verifiers and acceptors in the network.
The HMAC key MAY be wrapped using the NIST AES-KW algorithm and The HMAC key MAY be included as a security parameter in which case
the results of the wrapping added as the wrapped key security it MUST be wrapped using the NIST AES-KW algorithm and the results
parameter for the BIB. of the wrapping added as the wrapped key security parameter for
the BIB.
The SHA variant used by this security context SHOULD be added as The SHA variant used by this security context SHOULD be added as
the SHA variant security parameter for the BIB if it differs from the SHA variant security parameter for the BIB if it differs from
the default key length. Otherwise, this parameter MAY be omitted the default key length. Otherwise, this parameter MAY be omitted
if doing so provides a useful reduction in message sizes. if doing so provides a useful reduction in message sizes.
Problems encountered in the keyed hash generation MUST be processed Problems encountered in the keyed hash generation MUST be processed
in accordance with local BPSec security policy. in accordance with local BPSec security policy.
3.7.2. Keyed Hash Verification 3.8.2. Keyed Hash Verification
During keyed hash verification, the input of the security target and During keyed hash verification, the input of the security target and
a HMAC key are provided to the appropriate HMAC/SHA2 algorithm. a HMAC key are provided to the appropriate HMAC/SHA2 algorithm.
During keyed hash verification, two inputs are prepared for the During keyed hash verification, two inputs are prepared for the
appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These
data items MUST be generated as follows. data items MUST be generated as follows.
The HMAC key MUST be derived using the wrapped key security The HMAC key MUST be derived using the wrapped key security
parameter if such a parameter is included in the security context parameter if such a parameter is included in the security context
parameters of the BIB. Otherwise, this key MUST be derived in parameters of the BIB. Otherwise, this key MUST be derived in
accordance with security policy at the verifying node as discussed accordance with security policy at the verifying node as discussed
in Section 3.5. in Section 3.5.
The IPPT MUST be generated as discussed in Section 3.6 with the The IPPT MUST be generated as discussed in Section 3.7 with the
value of integrity scope flags being taken from the integrity value of integrity scope flags being taken from the integrity
scope flags security context parameter. If the integrity scope scope flags security context parameter. If the integrity scope
flags parameter is not included in the security context parameters flags parameter is not included in the security context parameters
then these flags MAY be derived from local security policy. then these flags MAY be derived from local security policy.
The calculated HMAC output MUST be compared to the expected HMAC The calculated HMAC output MUST be compared to the expected HMAC
output encoded in the security results of the BIB for the security output encoded in the security results of the BIB for the security
target. If the calculated HMAC and expected HMAC are identical, the target. If the calculated HMAC and expected HMAC are identical, the
verification MUST be considered a success. Otherwise, the verification MUST be considered a success. Otherwise, the
verification MUST be considered a failure. verification MUST be considered a failure.
skipping to change at page 13, line 39 skipping to change at page 14, line 42
the set of information used to generate an authentication tag. the set of information used to generate an authentication tag.
The scope of the confidentiality service defines the set of The scope of the confidentiality service defines the set of
information provided to the AES-GCM cipher for the purpose of information provided to the AES-GCM cipher for the purpose of
producing cipher text. This MUST be the full set of plain text producing cipher text. This MUST be the full set of plain text
contained in the block-type-specific data field of the security contained in the block-type-specific data field of the security
target. target.
The scope of the authentication service defines the set of The scope of the authentication service defines the set of
information used to generate an authentication tag carried with the information used to generate an authentication tag carried with the
security block. This information includes the data included in the security block. This information contains all data protected by the
confidentiality service and MAY include other information (additional confidentiality service, the scope flags used to identify other
optional information, and MAY include other information (additional
authenticated data), as follows. authenticated data), as follows.
Primary block Primary block
The primary block identifies a bundle and, once created, the The primary block identifies a bundle and, once created, the
contents of this block are immutable. Changes to the primary contents of this block are immutable. Changes to the primary
block associated with the security target indicate that the block associated with the security target indicate that the
security target (and BCB) might no longer be in the correct security target (and BCB) might no longer be in the correct
bundle. bundle.
For example, if a security target and associated BCB are copied For example, if a security target and associated BCB are copied
skipping to change at page 15, line 5 skipping to change at page 16, line 5
data ensures that the policy and identification of the security data ensures that the policy and identification of the security
service in the bundle has not changed. service in the bundle has not changed.
NOTE: The security context identifier and security context NOTE: The security context identifier and security context
parameters of the security block are not included as additional parameters of the security block are not included as 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. those needed to verify or accept the security service.
Therefore, it is expected that changes to these values would Therefore, it is expected that changes to these values would
result in failures at security verifiers and security acceptors. result in failures at security verifiers and security acceptors.
This is the case because keys cannot be re-used across security
contexts, and because the AAD scope flags used to identify the
AAD are included in the AAD.
The scope of the BCB-AES-GCM security context is configured using an The scope of the BCB-AES-GCM security context is configured using an
optional security context parameter. optional security context parameter.
4.3. Parameters 4.3. Parameters
BCB-AES-GCM can be parameterized to specify the AES variant, BCB-AES-GCM can be parameterized to specify the AES variant,
initialization vector, key information, and identify additional initialization vector, key information, and identify additional
authenticated data. authenticated data.
4.3.1. Initialization Vector (IV) 4.3.1. Initialization Vector (IV)
skipping to change at page 16, line 15 skipping to change at page 17, line 27
(indicating use of A256GCM), unless an alternate default is (indicating use of A256GCM), unless an alternate default is
established by local security policy at the security source, established by local security policy at the security source,
verifier, or acceptor of this integrity service. verifier, or acceptor of this integrity service.
Regardless of the variant, the generated authentication tag MUST Regardless of the variant, the generated authentication tag MUST
always be 128 bits. always be 128 bits.
4.3.3. Wrapped Key 4.3.3. Wrapped Key
This optional parameter contains the output of the AES key wrap This optional parameter contains the output of the AES key wrap
authenticated encryption function (KW-AE) as defined in [AES-KW]. authenticated encryption function (KW-AE) as defined in [RFC5649].
Specifically, this parameter holds the cipher text produced when Specifically, this parameter holds the cipher text produced when
running the KW-AE algorithm with the input string being the symmetric running the KW-AE algorithm with the input string being the symmetric
AES key used to generate the security results present in the security AES key used to generate the security results present in the security
block. The value of this parameter is used as input to the AES key block. The value of this parameter is used as input to the AES key
wrap authenticated decryption function (KW-AD) at security verifiers wrap authenticated decryption function (KW-AD) at security verifiers
and security acceptors to determine the symmetric AES key needed for and security acceptors to determine the symmetric AES key needed for
the proper decryption of the security results in the security block. the proper decryption of the security results in the security block.
This value MUST be encoded as a CBOR byte string. This value MUST be encoded as a CBOR byte string.
skipping to change at page 16, line 44 skipping to change at page 18, line 7
the security target as part of additional authenticated data (AAD). the security target as part of additional authenticated data (AAD).
This value MUST be represented as a CBOR unsigned integer, the value This value MUST be represented as a CBOR unsigned integer, the value
of which MUST be processed as a bit field. of which MUST be processed as a bit field.
AAD scope flags that are unrecognized MUST be ignored, as future AAD scope flags that are unrecognized MUST be ignored, as future
definitions of additional flags might not be integrated definitions of additional flags might not be integrated
simultaneously into security context implementations operating at all simultaneously into security context implementations operating at all
nodes. nodes.
Implementations MUST set reserved and unassigned bits in this field
to 0 when constructing these flags at a security source. Once set,
the value of this field MUST NOT be altered until the security
service is completed at the security acceptor in the network and
removed from the bundle.
Bits in this field represent additional information to be included Bits in this field represent additional information to be included
when generating an integrity signature over the security target. when generating an integrity signature over the security target.
These bits are defined as follows. These bits are defined as follows.
- Bit 0 (the low-order bit, 0x0001): Primary Block Flag. - Bit 0 (the low-order bit, 0x0001): Primary Block Flag.
- Bit 1 (0x0002): Target Header Flag. - Bit 1 (0x0002): Target Header Flag.
- Bit 2 (0x0003): Security Header Flag. - Bit 2 (0x0004): Security Header Flag.
- Bits 3-7 are reserved. - Bits 3-7 are reserved.
- Bits 8-15 are unassigned. - Bits 8-15 are unassigned.
4.3.5. Enumerations 4.3.5. Enumerations
BCB-AES-GCM defines the following security context parameters. The BCB-AES-GCM security context parameters are listed in Table 4.
In this table, the "Parm Id" column refers to the expected Parameter
Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter
and Result Identification".
If the default value column is empty, this indicates that the
security parameter does not have a default value.
BCB-AES-GCM Security Parameters BCB-AES-GCM Security Parameters
+----+-----------------------+--------------------+---------------+ +---------+----------------------+------------------+---------------+
| Id | Name | CBOR Encoding Type | Default Value | | Parm Id | Parm Name | CBOR Encoding | Default Value |
+----+-----------------------+--------------------+---------------+ | | | Type | |
| 1 | Initialization Vector | Byte String | NONE | +---------+----------------------+------------------+---------------+
| 2 | AES Variant | UINT | 3 | | 1 | Initialization | Byte String | |
| 3 | Wrapped Key | Byte String | NONE | | | Vector | | |
| 4 | AAD Scope Flags | UINT | 0x7 | | 2 | AES Variant | Unsigned Integer | 3 |
+----+-----------------------+--------------------+---------------+ | 3 | Wrapped Key | Byte String | |
| 4 | AAD Scope Flags | Unsigned Integer | 7 |
+---------+----------------------+------------------+---------------+
Table 4 Table 4
4.4. Results 4.4. Results
The BCB-AES-GCM security context produces a single security result The BCB-AES-GCM security context produces a single security result
carried in the security block: the authentication tag. carried in the security block: the authentication tag.
NOTES: NOTES:
skipping to change at page 18, line 25 skipping to change at page 19, line 47
security result MUST NOT be included in the BCB for that security security result MUST NOT be included in the BCB for that security
target. target.
The length of the authentication tag, prior to any CBOR encoding, The length of the authentication tag, prior to any CBOR encoding,
MUST be 128 bits. MUST be 128 bits.
This value MUST be encoded as a CBOR byte string. This value MUST be encoded as a CBOR byte string.
4.4.2. Enumerations 4.4.2. Enumerations
BCB-AES-GCM defines the following security context parameters. The BCB-AES-GCM security context results are listed in Table 5. In
this table, the "Result Id" column refers to the expected Result
Identifier described in [I-D.ietf-dtn-bpsec], Section 3.10 "Parameter
and Result Identification".
BCB-AES-GCM Security Results BCB-AES-GCM Security Results
+-----------+--------------------+--------------------+ +-----------+--------------------+--------------------+
| Result Id | Result Name | CBOR Encoding Type | | Result Id | Result Name | CBOR Encoding Type |
+-----------+--------------------+--------------------+ +-----------+--------------------+--------------------+
| 1 | Authentication Tag | Byte String | | 1 | Authentication Tag | Byte String |
+-----------+--------------------+--------------------+ +-----------+--------------------+--------------------+
Table 5 Table 5
4.5. Key Considerations 4.5. Key Considerations
Keys used with this context MUST be symmetric and MUST have a key Keys used with this context MUST be symmetric and MUST have a key
length equal to the key length defined in the security context length equal to the key length defined in the security context
parameters or as defined by local security policy at security parameters or as defined by local security policy at security
verifiers and acceptors. For this reason, content-encrypting keys verifiers and acceptors. For this reason, content-encrypting key
will be integer divisible by 8 bytes and special padding-aware AES lengths will be integer divisible by 8 bytes and special padding-
key wrap algorithms are not needed. aware AES key wrap algorithms are not needed.
It is assumed that any security verifier or security acceptor can It is assumed that any security verifier or security acceptor can
determine the proper key to be used. Potential sources of the key 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.
Pre-placed keys selected based on local policy. Pre-placed keys selected based on local policy.
Keys extracted from material carried in the BCB. Keys extracted from material carried in the BCB.
Session keys negotiated via a mechanism external to the BCB. Session keys negotiated via a mechanism external to the BCB.
When an AES-KW wrapped key is present in a security block, it is When an AES-KW wrapped key is present in a security block, it is
assumed that security verifiers and security acceptors can assumed that security verifiers and security acceptors can
independently determine the key encryption key (KEK) used in the independently determine the key encryption key (KEK) used in the
wrapping of the symmetric AES content-encrypting key. wrapping of the symmetric AES content-encrypting key.
The security provided by block ciphers is reduced as more data is The security provided by block ciphers is reduced as more data is
processed with the same key. The total number of bytes processed processed with the same key. The total number of blocks processed
with a single key for AES-GCM is recommended to be less than 2^64, as with a single key for AES-GCM is recommended to be less than 2^64, as
described in Appendix B of [AES-GCM]. described in Appendix B of [AES-GCM].
Additionally, there exist limits on the number of encryptions that
can be performed with the same key. The total number of invocations
of the authenticated encryption function with a single key for AES-
GCM is required to not exceed 2^32, as described in Section 8.3 of
[AES-GCM].
As discussed in Section 6 and emphasized here, it is strongly As discussed in Section 6 and emphasized here, it is strongly
recommended that keys be protected once generated, both when they are recommended that keys be protected once generated, both when they are
stored and when they are transmitted. stored and when they are transmitted.
4.6. GCM Considerations 4.6. GCM Considerations
The GCM cryptographic mode of AES has specific requirements that MUST The GCM cryptographic mode of AES has specific requirements that MUST
be followed by implementers for the secure function of the BCB-AES- be followed by implementers for the secure function of the BCB-AES-
GCM security context. While these requirements are well documented GCM security context. While these requirements are well documented
in [AES-GCM], some of them are repeated here for emphasis. in [AES-GCM], some of them are repeated here for emphasis.
The pairing of an IV and a security key MUST be unique. An IV With the exception of the AES-KW function, the IVs used by the
MUST NOT be used with a security key more than one time. If an IV BCB-AES-GCM security context are considered to be per-invocation
and key pair are repeated then the GCM implementation is IVs. The pairing of a per-invocation IV and a security key MUST
vulnerable to forgery attacks. More information regarding the be unique. A per-invocation IV MUST NOT be used with a security
importance of the uniqueness of the IV value can be found in key more than one time. If a per-invocation IV and key pair are
Appendix A of [AES-GCM]. repeated then the GCM implementation is vulnerable to forgery
attacks. More information regarding the importance of the
uniqueness of the IV value can be found in Appendix A of
[AES-GCM].
The AES-KW function used to wrap keys for the security contexts in
this document uses a single, globally constant IV input to the AES
cipher operation and, thus, is distinct from the aforementioned
requirement related to per-invocation IVs.
While any tag-based authentication mechanism has some likelihood 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 SHOULD be avoided when using this mode. The BCB-AES-GCM 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 [AES-GCM]. discussed in Appendices B and C of [AES-GCM].
As discussed in Appendix B of [AES-GCM], implementations SHOULD As discussed in Appendix B of [AES-GCM], implementations SHOULD
limit the number of unsuccessful verification attempts for each limit the number of unsuccessful verification attempts for each
key to reduce the likelihood of guessing tag values. key to reduce the likelihood of guessing tag values. This type of
check has potential state-keeping issues when AES-KW is used,
since an attacker could cause a large number of keys to have been
used at least once.
As discussed in the Security Considerations section of As discussed in the Security Considerations section of
[I-D.ietf-dtn-bpsec], delay-tolerant networks have a higher [I-D.ietf-dtn-bpsec], 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 SHOULD attempt to detect replay attacks
by using mechanisms such as those described in Appendix D of by using mechanisms such as those described in Appendix D of
[AES-GCM]. [AES-GCM].
4.7. Canonicalization Algorithms 4.7. Canonicalization Algorithms
skipping to change at page 20, line 22 skipping to change at page 22, line 20
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 [I-D.ietf-dtn-bpsec]. The MUST be performed as described in [I-D.ietf-dtn-bpsec]. The
canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to canonicalization algorithms defined in [I-D.ietf-dtn-bpsec] adhere to
the canonical forms for extension blocks defined in the canonical forms for extension blocks defined in
[I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values [I-D.ietf-dtn-bpbis] but resolve ambiguities related to how values
are represented in CBOR. are represented in CBOR.
4.7.1. Cipher text related calculations 4.7.1. Cipher text related calculations
The plain text used during encryption MUST be calculated as the The BCB operates over the block-type-specific data of a block, but
single, definite-length CBOR byte string representing the block-type- the BP always encodes these data within a single, definite-length
specific data field of the security target excluding the CBOR byte CBOR byte string. Therefore, the plain text used during encryption
string identifying byte and optional CBOR byte string length field. MUST be calculated as the value of the block-type-specific data field
of the security target excluding any CBOR encoding.
For example, consider the following two CBOR byte strings and the Consider the following two CBOR encoded examples and the plain text
plain text that would be extracted from them. that would be extracted from them. The first example is an unsigned
integer, while the second is a byte string.
CBOR Byte String Examples CBOR Plain Text Extraction Examples
+------------------------------+---------+--------------------------+ +------------------------------+---------+--------------------------+
| CBOR Byte String (Hex) | CBOR | Plain Text Part (Hex) | | CBOR Encoding (Hex) | CBOR | Plain Text Part (Hex) |
| | Part | | | | Part | |
| | (Hex) | | | | (Hex) | |
+------------------------------+---------+--------------------------+ +------------------------------+---------+--------------------------+
| 18ED | 18 | ED | | 18ED | 18 | ED |
+------------------------------+---------+--------------------------+ +------------------------------+---------+--------------------------+
| C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF | | C24CDEADBEEFDEADBEEFDEADBEEF | C24C | DEADBEEFDEADBEEFDEADBEEF |
+------------------------------+---------+--------------------------+ +------------------------------+---------+--------------------------+
Table 6 Table 6
skipping to change at page 21, line 12 skipping to change at page 23, line 12
block number, block processing control flags, or any CRC information) block number, block processing control flags, or any CRC information)
MUST NOT be considered as part of encryption or decryption. MUST NOT be considered as part of encryption or decryption.
4.7.2. Additional Authenticated Data 4.7.2. Additional Authenticated Data
The construction of additional authenticated data depends on the AAD The construction of additional authenticated data depends on the AAD
scope flags that can be provided as part of customizing the behavior scope flags that can be provided as part of customizing the behavior
of this security context. of this security context.
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. This process MUST be constructed using the following process. While the AAD scope flags
might not be included in the BCB representing the security operation,
they MUST be included in the AAD value itself. This process MUST be
followed when generating AAD for either encryption or decryption. followed when generating AAD for either encryption or decryption.
1. The canonical form of the AAD starts as the empty set with length 1. The canonical form of the AAD starts as the CBOR encoding of the
0. AAD scope flags in which all unset flags, reserved bits, and
unassigned bits have been set to 0. For example, if the primary
2. If the AAD scope parameter is present and the primary block flag block flag, target header flag, and security header flag are each
is set to 1, then a canonical form of the bundle's primary block set, then the initial value of the canonical form of the AAD will
MUST be calculated and the result appended to the AAD. be 0x07.
3. If the AAD scope parameter is present and the target header flag 2. If the primary block flag of the AAD scope flags is set to 1,
is set to 1, then the canonical form of the block type code, then a canonical form of the bundle's primary block MUST be
block number, and block processing control flags associated with calculated and the result appended to the AAD.
the security target MUST be calculated and, in that order,
appended to the AAD.
4. If the AAD scope parameter is present and the security header 3. If the target header flag of the AAD scope flags is set to 1,
flag 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 number, and block processing control flags associated with block processing control flags associated with the security
the BIB MUST be calculated and, in that order, appended to the target MUST be calculated and, in that order, appended to the
AAD. AAD.
If, after this process, the AAD remains at length 0, then no AAD 4. If the security header flag of the AAD scope flags is set to 1,
exists to be input to the cipher suite. then the canonical form of the block type code, block number, and
block processing control flags associated with the BIB MUST be
calculated and, in that order, appended to the AAD.
4.8. Processing 4.8. Processing
4.8.1. Encryption 4.8.1. Encryption
During encryption, four inputs are prepared for input to the AES/GCM During encryption, four inputs are prepared for input to the AES/GCM
cipher: the encryption key, the IV, the security target plain text to cipher: the encryption key, the IV, the security target plain text to
be encrypted, and any additional authenticated data. These data be encrypted, and any additional authenticated data. These data
items MUST be generated as follows. items MUST be generated as follows.
skipping to change at page 22, line 18 skipping to change at page 24, line 20
The IV selected MUST be of the appropriate length. Because The IV selected MUST be of the appropriate length. Because
replaying an IV in counter mode voids the confidentiality of all replaying an IV in counter mode voids the confidentiality of all
messages encrypted with said IV, this context also requires a messages encrypted with said IV, this context also requires a
unique IV for every encryption performed with the same key. This unique IV for every encryption performed with the same key. This
means the same key and IV combination MUST NOT be used more than means the same key and IV combination MUST NOT be used more than
once. once.
The security target plain text for encryption MUST be generated as The security target plain text for encryption MUST be generated as
discussed in Section 4.7.1. discussed in Section 4.7.1.
Additional authenticated data, if present, MUST be generated as Additional authenticated data MUST be generated as discussed in
discussed in Section 4.7.2 with the value of AAD scope flags being Section 4.7.2 with the value of AAD scope flags being taken from
taken from local security policy. local security policy.
Upon successful encryption the following actions MUST occur. Upon successful encryption the following actions MUST occur.
The cipher text produced by AES/GCM MUST replace the bytes used to The cipher text produced by AES/GCM MUST replace the bytes used to
define the plain text in the security target block's block-type- define the plain text in the security target block's block-type-
specific data field. The block length of the security target MUST specific data field. The block length of the security target MUST
be updated if the generated cipher text is larger than the plain be updated if the generated cipher text is larger than the plain
text (which can occur when the authentication tag is included in text (which can occur when the authentication tag is included in
the cipher text calculation, as discussed in Section 4.4). the cipher text calculation, as discussed in Section 4.4).
The authentication tag calculated by the AES/GCM cipher MUST be The authentication tag calculated by the AES/GCM cipher MAY be
added as a security result for the security target in the BCB added as a security result for the security target in the BCB
holding results for this security operation. holding results for this security operation, in which case it MUST
be processed as described in Section 4.4.
Cases where the authentication tag is generated as part of the The authentication tag MUST be included either as a security
cipher text MUST be processed as described in Section 4.4. result in the BCB representing the security operation or (with the
cipher text) in the security target block-type-specific data
field.
Finally, the BCB containing information about this security operation Finally, the BCB containing information about this security operation
MUST be updated as follows. These operations can occur in any order. MUST be updated as follows. These operations can occur in any order.
The security context identifier for the BCB MUST be set to the The security context identifier for the BCB MUST be set to the
context identifier for BCB-AES-GCM. context identifier for BCB-AES-GCM.
The IV input to the cipher MUST be added as the IV security The IV input to the cipher MUST be added as the IV security
parameter for the BCB. parameter for the BCB.
Any local flags used to generated AAD for this cipher MUST be Any local flags used to generated AAD for this cipher MUST be
added as the AAD scope flags security parameter for the BCB. placed in the AAD scope flags security parameter for the BCB
unless these flags are expected to be correctly configured at
security verifiers and security acceptors in the network.
The encryption key MAY be wrapped using the NIST AES-KW algorithm The encryption key MAY be included as a security parameter in
and the results of the wrapping added as the wrapped key security which case it MUST be wrapped using the NIST AES-KW algorithm and
the results of the wrapping added as the wrapped key security
parameter for the BCB. parameter for the BCB.
The key length used by this security context MUST be considered The AES variant used by this security context SHOULD be added as
when setting the AES variant security parameter for the BCB if it the AES variant security parameter for the BCB if it differs from
differs from the default AES variant. Otherwise, the AES variant the default key length. Otherwise, this parameter MAY be omitted
MAY be omitted if doing so provides a useful reduction in message if doing so provides a useful reduction in message sizes.
sizes.
Problems encountered in the encryption MUST be processed in Problems encountered in the encryption MUST be processed in
accordance with local security policy. This MAY include restoring a accordance with local security policy. This MAY include restoring a
CRC value removed from the target block prior to encryption, if the CRC value removed from the target block prior to encryption, if the
target block is allowed to be transmitted after an encryption error. target block is allowed to be transmitted after an encryption error.
4.8.2. Decryption 4.8.2. Decryption
During encryption, five inputs are prepared for input to the AES/GCM During decryption, five inputs are prepared for input to the AES/GCM
cipher: the decryption key, the IV, the security target cipher text cipher: the decryption key, the IV, the security target cipher text
to be decrypted, any additional authenticated data, and the to be decrypted, any additional authenticated data, and the
authentication tag generated from the original encryption. These authentication tag generated from the original encryption. These
data items MUST be generated as follows. data items MUST be generated as follows.
The decryption key MUST be derived using the wrapped key security The decryption key MUST be derived using the wrapped key security
parameter if such a parameter is included in the security context parameter if such a parameter is included in the security context
parameters of the BCB. Otherwise this key MUST be derived in parameters of the BCB. Otherwise this key MUST be derived in
accordance with local security policy at the decrypting node as accordance with local security policy at the decrypting node as
discussed in Section 4.5. discussed in Section 4.5.
skipping to change at page 23, line 44 skipping to change at page 25, line 49
The IV MUST be set to the value of the IV security parameter The IV MUST be set to the value of the IV security parameter
included in the BCB. If the IV parameter is not included as a included in the BCB. If the IV parameter is not included as a
security parameter, an IV MAY be derived as a function of local security parameter, an IV MAY be derived as a function of local
security policy and other BCB contents or a lack of an IV security security policy and other BCB contents or a lack of an IV security
parameter in the BCB MAY be treated as an error by the decrypting parameter in the BCB MAY be treated as an error by the decrypting
node. node.
The security target cipher text for decryption MUST be generated The security target cipher text for decryption MUST be generated
as discussed in Section 4.7.1. as discussed in Section 4.7.1.
Additional authenticated data, if present, MUST be generated as Additional authenticated data MUST be generated as discussed in
discussed in Section 4.7.2 with the value of AAD scope flags being Section 4.7.2 with the value of AAD scope flags being taken from
taken from the AAD scope flags security context parameter. If the the AAD scope flags security context parameter. If the AAD scope
AAD scope flags parameter is not included in the security context flags parameter is not included in the security context parameters
parameters then these flags MAY be derived from local security then these flags MAY be derived from local security policy in
policy in cases where the set of such flags is determinable in the cases where the set of such flags is determinable in the network.
network.
The authentication tag MUST be present in the BCB security context The authentication tag MUST be present in the BCB security context
parameters field if additional authenticated data are defined for parameters field. This tag MUST be 128 bits in length.
the BCB (either in the AAD scope flags parameter or as specified
by local policy). This tag MUST be 128 bits in length.
Upon successful decryption the following actions MUST occur. Upon successful decryption the following actions MUST occur.
The plain text produced by AES/GCM MUST replace the bytes used to The plain text produced by AES/GCM MUST replace the bytes used to
define the cipher text in the security target block's block-type- define the cipher text in the security target block's block-type-
specific data field. Any changes to the security target block specific data field. Any changes to the security target block
length field MUST be corrected in cases where the plain text has a length field MUST be corrected in cases where the plain text has a
different length than the replaced cipher text. different length than the replaced cipher text.
If the security acceptor is not the bundle destination and if no If the security acceptor is not the bundle destination and if no
skipping to change at page 26, line 25 skipping to change at page 28, line 25
| 2 | Include security header | This | | 2 | Include security header | This |
| | flag | document | | | flag | document |
| 3-7 | reserved | This | | 3-7 | reserved | This |
| | | document | | | | document |
| 8-15 | unassigned | This | | 8-15 | unassigned | This |
| | | document | | | | document |
+-------------------------+--------------------------+--------------+ +-------------------------+--------------------------+--------------+
Table 9 Table 9
5.4. Guidance for Designated Experts
New assignments within the BIB-HMAC-SHA2 Integrity Scope Flags
Registry and the BCB-AES-GCM AAD Scope Flags Registry require review
by a Designated Expert (DE). This section provides guidance to the
DE when performing their reviews. Specifically, a DE is expected to
perform the following activities.
o Ascertain the existence of suitable documentation (a
specification) as described in [RFC8126] and to verify that the
document is permanently and publicly available.
o Ensure that any changes to the Integrity Scope Flags clearly state
how new assignments interact with existing flags and how the
inclusion of new assignments affects the construction of the IPPT
value.
o Ensure that any changes to the AAD Scope Flags clearly state how
new assignments interact with existing flags and how the inclusion
of new assignments affects the construction of the AAD input to
the BCB-AES-GCM mechanism.
o Ensure that any processing changes proposed with new assignments
do not alter any required behavior in this specification.
o Verify that any specification produced in the IETF has been made
available for review by the DTN working group and that any
specification produced outside of the IETF does not conflict with
work that is active or already published within the IETF.
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 can any security context described in this document. Considerations can
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 Management 6.1. Key Management
skipping to change at page 27, line 5 skipping to change at page 29, line 36
In these environments, key establishment protocols that rely on In these environments, key establishment protocols that rely on
round-trip information exchange might not converge on a shared secret round-trip information exchange might not converge on a shared secret
in a timely manner (or at all). Also, key revocation or key in a timely manner (or at all). Also, key revocation or key
verification mechanisms that rely on access to a centralized verification mechanisms that rely on access to a centralized
authority (such as a certificate authority) might similarly fail in authority (such as a certificate authority) might similarly fail in
the stressing conditions of a DTN. the stressing conditions of a DTN.
For these reasons, the default security contexts described in this For these reasons, the default security contexts described in this
document rely on symmetric key cryptographic mechanisms because document rely on symmetric key cryptographic mechanisms because
asymmetric key infrastructure (such as a public key infrastructure) asymmetric key infrastructure (such as a public key infrastructure)
is impractical in this environment. This extends to any asymmetric- might be impractical in this environment.
key mechanism for key derivation, key exchange, or key revocation.
BPSec assumes that "key management is handled as a separate part of BPSec assumes that "key management is handled as a separate part of
network management" [I-D.ietf-dtn-bpsec]. This assumption is also network management" [I-D.ietf-dtn-bpsec]. This assumption is also
made by the security contexts defined in this document which do not made by the security contexts defined in this document which do not
define new protocols for key derivation, exchange of key-encrypting define new protocols for key derivation, exchange of key-encrypting
keys, revocation of existing keys, or the security configuration or keys, revocation of existing keys, or the security configuration or
policy used to select certain keys for certain security operations. policy used to select certain keys for certain security operations.
Nodes using these security contexts need to perform the following Nodes using these security contexts need to perform the following
kinds of activities, independent of the construction, transmission, kinds of activities, independent of the construction, transmission,
skipping to change at page 28, line 8 skipping to change at page 30, line 38
6.2. Key Handling 6.2. Key Handling
Once generated, keys should be handled as follows. 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 be treated as providing integrity when
compromised key and BCB-AES-GCM SHOULD NOT provide confidentiality used with a compromised key and BCB-AES-GCM SHOULD NOT be treated
when used with a compromised key. as providing confidentiality when used with a compromised key.
The same key SHOULD NOT be used for different algorithms as doing The same key, whether a key-encrypting-key or a wrapped key, MUST
so might leak information about the key. NOT be used for different algorithms as doing so might leak
information about the key.
A key-encrypting-key MUST NOT be used to encrypt keys for
different security contexts. Any key-encrypting-key used by a
security context defined in this document MUST only be used to
wrap keys associated with security operations using that security
context. This means that a compliant security source would not
use the same key-encrypting-key to wrap keys for both the BIB-
HMAC-SHA2 and BCB-AES-GCM security contexts. Similarly, any
compliant security verifier or security acceptor would not use the
same key-encrypting-key to unwrap keys for different security
contexts.
6.3. AES GCM 6.3. AES GCM
There are a significant number of considerations related to the use There are a significant number of considerations related to the use
of the GCM mode of AES to provide a confidentiality service. These of the GCM mode of AES to provide a confidentiality service. These
considerations are provided in Section 4.6 as part of the considerations are provided in Section 4.6 as part of the
documentation of the BCB-AES-GCM security context. documentation of the BCB-AES-GCM security context.
The length of the cipher text produced by the GCM mode of AES will be The length of the cipher text produced by the GCM mode of AES will be
equal to the length of the plain text input to the cipher suite. The equal to the length of the plain text input to the cipher suite. The
skipping to change at page 28, line 45 skipping to change at page 31, line 39
block. Implementations MAY use the authentication tag security block. Implementations MAY use the authentication tag security
result in cases where keeping target block length unchanged is an result in cases where keeping target block length unchanged is an
important processing concern. In all cases, the cipher text and important processing concern. In all cases, the cipher text and
authentication tag MUST be processed in accordance with the API of authentication tag MUST be processed in accordance with the API of
the AES-GCM cipher suites at the security source and security the AES-GCM cipher suites at the security source and security
acceptor. acceptor.
6.4. AES Key Wrap 6.4. AES Key Wrap
The AES key wrap (AES-KW) algorithm used by the security contexts in The AES key wrap (AES-KW) algorithm used by the security contexts in
this document does not use an initialization vector and does not this document does not use a per-invocation initialization vector and
require any key padding. Key padding is not needed because wrapped does not require any key padding. Key padding is not needed because
keys used by these security contexts will always be multiples of 8 wrapped keys used by these security contexts will always be multiples
bytes. The length of the wrapped key can be determined by inspecting of 8 bytes. The length of the wrapped key can be determined by
the security context parameters. Therefore, a key can be unwrapped inspecting the security context parameters. Therefore, a key can be
using only the information present in the security block and the key unwrapped using only the information present in the security block
encryption key provided by local security policy at the security and the key encryption key provided by local security policy at the
verifier or security acceptor. security verifier or security acceptor.
6.5. Bundle Fragmentation 6.5. Bundle Fragmentation
Bundle fragmentation might prevent security services in a bundle from Bundle fragmentation might prevent security services in a bundle from
being verified after a bundle is fragmented and before the bundle is being verified after a bundle is fragmented and before the bundle is
re-assembled. Examples of potential issues include the following. re-assembled. Examples of potential issues include the following.
If a security block and its security target do not exist in the If a security block and its security target do not exist in the
same fragment, then the security block cannot be processed until same fragment, then the security block cannot be processed until
the bundle is re-assembled. If a fragment includes an encrypted the bundle is re-assembled. If a fragment includes an encrypted
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
encrypted. encrypted.
If a security block is cryptographically bound to a bundle, it A security block can be cryptographically bound to a bundle by
setting the Integrity Scope Flags (for BIB-HMAC-SHA2) or the AAD
Scope Flags (for BCB-AES-GCM) to include the bundle primary block.
When a security block is cryptographically bound to a bundle, it
cannot be processed even if the security block and target both cannot be processed even if the security block and target both
coexist in the fragment. This is because fragments have different coexist in the fragment. This is because fragments have different
primary blocks than the original bundle. primary blocks than the original bundle.
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 multiple fragments, policy needs to determine how to deal with
issues where a security operation verifies in one fragment but issues where a security operation verifies in one fragment but
fails in another fragment. This might happen, for example, if a fails in another fragment. This might happen, for example, if a
BIB block becomes corrupted in one fragment but not in another BIB block becomes corrupted in one fragment but not in another
fragment. fragment.
skipping to change at page 29, line 45 skipping to change at page 32, line 48
bound to a bundle, then a fragmenting BPA should consider bound to a bundle, then a fragmenting BPA should consider
encapsulating the bundle first and then fragmenting the encapsulating encapsulating the bundle first and then fragmenting the encapsulating
bundle. bundle.
7. Normative References 7. Normative References
[AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation: Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC.", November 2007. Galois/Counter Mode (GCM) and GMAC.", November 2007.
[AES-KW] Dworkin, M., "NIST Special Publication 800-38F:
Recommendation for Block Cipher Modes of Operation:
Methods for Key Wrapping.", December 2012.
[HMAC] US NIST, "The Keyed-Hash Message Authentication Code
(HMAC).", FIPS-198-1, Gaithersburg, MD, USA, July 2008.
https://csrc.nist.gov/publications/detail/fips/198/1/final
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
Version 7", draft-ietf-dtn-bpbis-31 (work in progress), Version 7", draft-ietf-dtn-bpbis-31 (work in progress),
January 2021. January 2021.
[I-D.ietf-dtn-bpsec] [I-D.ietf-dtn-bpsec]
Birrane, E. and K. McKeever, "Bundle Protocol Security Birrane, E. and K. McKeever, "Bundle Protocol Security
Specification", draft-ietf-dtn-bpsec-27 (work in Specification", draft-ietf-dtn-bpsec-27 (work in
progress), February 2021. progress), February 2021.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649,
DOI 10.17487/RFC5649, September 2009,
<https://www.rfc-editor.org/info/rfc5649>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8152] 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>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
skipping to change at page 31, line 9 skipping to change at page 34, line 21
document) and adding those blocks to a sample bundle. document) and adding those blocks to a sample bundle.
The examples presented in this appendix represent valid constructions The examples presented in this appendix represent valid constructions
of bundles, security blocks, and the encoding of security context of bundles, security blocks, and the encoding of security context
parameters and results. For this reason, they can inform unit test parameters and results. For this reason, they can inform unit test
suites for individual implementations as well as interoperability suites for individual implementations as well as interoperability
test suites amongst implementations. However, these examples do not test suites amongst implementations. However, these examples do not
cover every permutation of security parameters, security results, or cover every permutation of security parameters, security results, or
use of security blocks in a bundle. use of security blocks in a bundle.
NOTE: The bundle diagrams in this section are patterned after the
bundle diagrams used in [I-D.ietf-dtn-bpsec] Section 3.11 "BSP Block
Examples".
NOTE: Figures in this section identified as "(CBOR Diagnostic NOTE: Figures in this section identified as "(CBOR Diagnostic
Notation)" are represented using the CBOR diagnostic notation defined Notation)" are represented using the CBOR diagnostic notation defined
in [RFC8949]. This notation is used to express CBOR data structures in [RFC8949]. This notation is used to express CBOR data structures
in a manner that enables visual inspection. The bundles, security in a manner that enables visual inspection. The bundles, security
blocks, and security context contents in these figures are blocks, and security context contents in these figures are
represented using CBOR structures. In cases where BP blocks (to represented using CBOR structures. In cases where BP blocks (to
include BPSec security blocks) are comprised of a sequence of CBOR include BPSec security blocks) are comprised of a sequence of CBOR
objects, these objects are represented as a CBOR sequence as defined objects, these objects are represented as a CBOR sequence as defined
in [RFC8742]. in [RFC8742].
skipping to change at page 31, line 40 skipping to change at page 35, line 10
A.1.1. Original Bundle A.1.1. Original Bundle
The following diagram shows the original bundle before the BIB has The following diagram shows the original bundle before the BIB has
been added. been added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block | 0 | 1 | | Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 1: Example 1 Original Bundle Figure 1: Example 1 Original Bundle
A.1.1.1. Primary Block A.1.1.1. Primary Block
The BPv7 bundle has no special processing flags and no CRC is The BPv7 bundle has no special processing flags and no CRC is
provided because the primary block is expected to be protected by an provided because the primary block is expected to be protected by an
integrity service BIB using the BIB-HMAC-SHA2 security context. integrity service BIB using the BIB-HMAC-SHA2 security context.
skipping to change at page 33, line 47 skipping to change at page 37, line 13
added. added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Integrity Block | 11 | 2 | | Bundle Integrity Block | 11 | 2 |
| OP(bib-integrity, target=1) | | | | OP(bib-integrity, target=1) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block | 0 | 1 | | Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 3: Example 1 Resulting Bundle Figure 3: Example 1 Resulting Bundle
A.1.3. Bundle Integrity Block A.1.3. Bundle Integrity Block
In this example, a BIB is used to carry an integrity signature over In this example, a BIB is used to carry an integrity signature over
the payload block. the payload block.
A.1.3.1. Configuration, Parameters, and Results A.1.3.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters For this example, the following configuration and security parameters
are used to generate the security results indicated. are used to generate the security results indicated.
This BIB has a single target and includes a single security result: This BIB has a single target and includes a single security result:
the calculated signature over the payload block. the calculated signature over the payload block.
Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' Key : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
SHA Variant : HMAC 512/512 SHA Variant : HMAC 512/512
Scope Flags : 0 Scope Flags : h'00'
Payload Data: h'52656164792047656e65726174652061 Payload Data: h'52656164792047656e65726174652061
2033322062797465207061796c6f6164' 2033322062797465207061796c6f6164'
Signature : h'd8e7c3be29effa8779e7dcb0d3cadf53 Signature : h'0654d65992803252210e377d66d0a8dc
39df50ebd27b9054f197c8ea9864b0a3 18a1e8a392269125ae9ac198a9a598be
35a0636213e5d4a9c95504f261d91a2f 4b83d5daa8be2f2d16769ec1c30cfc34
22757112c95e3587a76b4228361803e8' 8e2205fba4b3be2b219074fdd5ea8ef0'
Figure 4: Example 1: Configuration, Parameters, and Results Figure 4: Example 1: Configuration, Parameters, and Results
A.1.3.2. Abstract Security Block A.1.3.2. Abstract Security Block
The abstract security block structure of the BIB's block-type- The abstract security block structure of the BIB's block-type-
specific-data field for this application is as follows. specific-data field for this application is as follows.
[1], / Security Target / [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, 0] / Scope Flags - No Additional Scope / [3, h'00'] / Scope Flags - No Additional Scope /
], ],
[ / Security Results: 1 Result / [ / Security Results: 1 Result /
[1, h'd8e7c3be29effa8779e7dcb0d3cadf5339df50ebd27b9054f197c8ea9864 [1, h'0654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598b
b0a335a0636213e5d4a9c95504f261d91a2f22757112c95e3587a76b4228 e4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0']
361803e8'] ]
]
Figure 5: Example 1: BIB Abstract Security Block (CBOR Diagnostic Figure 5: Example 1: BIB Abstract Security Block (CBOR Diagnostic
Notation) Notation)
The CBOR encoding of the BIB block-type-specific-data field (the The CBOR encoding of the BIB block-type-specific-data field (the
abstract security block) is 0x810101018202820201828201078203008182015 abstract security block) is 0x810101018202820201828201078203008182015
840d8e7c3be29effa8779e7dcb0d3cadf5339df50ebd27b9054f197c8ea9864b0a335 8400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b
a0636213e5d4a9c95504f261d91a2f22757112c95e3587a76b4228361803e8. 83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0.
A.1.3.3. Representations A.1.3.3. Representations
The BIB wrapping this abstract security block is as follows. The BIB wrapping this abstract security block is as follows.
[ [
11, / type code / 11, / type code /
2, / block number / 2, / block number /
0, / flags / 0, / flags /
0, / CRC type / 0, / CRC type /
h'810101018202820201828201078203008182015840d8e7c3be29effa8779e7dcb h'8101010182028202018282010782030081820158400654d65992803252210e377d66
0d3cadf5339df50ebd27b9054f197c8ea9864b0a335a0636213e5d4a9c95504f2 d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc34
61d91a2f22757112c95e3587a76b4228361803e8', 8e2205fba4b3be2b219074fdd5ea8ef0',
] ]
Figure 6: Example 1: BIB (CBOR Diagnostic Notation) Figure 6: Example 1: BIB (CBOR Diagnostic Notation)
The CBOR encoding of the BIB block is 0x850b0200005855810101018202820 The CBOR encoding of the BIB block is 0x850b0200005855810101018202820
201828201078203008182015840d8e7c3be29effa8779e7dcb0d3cadf5339df50ebd2 2018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392
7b9054f197c8ea9864b0a335a0636213e5d4a9c95504f261d91a2f22757112c95e358 269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2
7a76b4228361803e8. b219074fdd5ea8ef0.
A.1.4. Final Bundle A.1.4. Final Bundle
The CBOR encoding of the full output bundle, with the BIB: 0x9F880700 The CBOR encoding of the full output bundle, with the BIB: 0x9f880700
00820282010282028202018202820201820018281a000f4240850b020000585581010 00820282010282028202018202820201820018281a000f4240850b020000585581010
1018202820201828201078203008182015840d8e7c3be29effa8779e7dcb0d3cadf53 10182028202018282010782030081820158400654d65992803252210e377d66d0a8dc
39df50ebd27b9054f197c8ea9864b0a335a0636213e5d4a9c95504f261d91a2f22757 18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e220
112c95e3587a76b4228361803e8ff. 5fba4b3be2b219074fdd5ea8ef08501010000582052656164792047656e6572617465
20612033322062797465207061796c6f6164ff.
A.2. Example 2: Simple Confidentiality with Key Wrap A.2. Example 2: Simple Confidentiality with Key Wrap
This example shows the addition of a BCB to a sample bundle to This example shows the addition of a BCB to a sample bundle to
provide confidentiality for the payload block. AES key wrap is used provide confidentiality for the payload block. AES key wrap is used
to transmit the symmetric key used to generate the security results to transmit the symmetric key used to generate the security results
for this service. for this service.
A.2.1. Original Bundle A.2.1. Original Bundle
The following diagram shows the original bundle before the BCB has The following diagram shows the original bundle before the BCB has
been added. been added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block | 0 | 1 | | Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 7: Example 2 Original Bundle Figure 7: Example 2 Original Bundle
A.2.1.1. Primary Block A.2.1.1. Primary Block
The primary block used in this example is identical to the primary The primary block used in this example is identical to the primary
block presented in Example 1 Appendix A.1.1.1. block presented in Example 1 Appendix A.1.1.1.
In summary, the CBOR encoding of the primary block is In summary, the CBOR encoding of the primary block is
skipping to change at page 37, line 13 skipping to change at page 40, line 26
added. added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Confidentiality Block | 12 | 2 | | Bundle Confidentiality Block | 12 | 2 |
| OP(bcb-confidentiality, target=1) | | | | OP(bcb-confidentiality, target=1) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 0 | 1 | | Payload Block (Encrypted) | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 8: Example 2 Resulting Bundle Figure 8: Example 2 Resulting Bundle
A.2.3. Bundle Confidentiality Block A.2.3. Bundle Confidentiality Block
In this example, a BCB is used to encrypt the payload block and uses In this example, a BCB is used to encrypt the payload block and uses
AES key wrap to transmit the symmetric key. AES key wrap to transmit the symmetric key.
A.2.3.1. Configuration, Parameters, and Results A.2.3.1. Configuration, Parameters, and Results
skipping to change at page 37, line 40 skipping to change at page 41, line 12
block-type-specific data to encrypt the payload block, an block-type-specific data to encrypt the payload block, an
authentication tag, and the AES wrapped key. authentication tag, and the AES wrapped key.
Content Encryption Content Encryption
Key: h'71776572747975696f70617364666768' Key: h'71776572747975696f70617364666768'
Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70' Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70'
IV: h'5477656c7665313231323132' IV: h'5477656c7665313231323132'
AES Variant: A128GCM AES Variant: A128GCM
AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892 AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892
96fabf34d7fae700' 96fabf34d7fae700'
Scope Flags: 0 Scope Flags: h'00'
Payload Data: h'52656164792047656e65726174652061 Payload Data: h'52656164792047656e65726174652061
2033322062797465207061796c6f6164' 2033322062797465207061796c6f6164'
Authentication Tag: h'689b98e649ae3b554e98aa2ae8f801eb' Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97'
Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354
a563e32648b700c2784e26a990d91f9d' a563e32648b700c2784e26a990d91f9d'
Figure 9: Example 2: Configuration, Parameters, and Results Figure 9: Example 2: Configuration, Parameters, and Results
A.2.3.2. Abstract Security Block A.2.3.2. Abstract Security Block
The abstract security block structure of the BCB's block-type- The abstract security block structure of the BCB's block-type-
specific-data field for this application is as follows. specific-data field for this application is as follows.
[1], / Security Target / [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, 0] / Scope Flags - No extra scope/ [4, h'00'] / Scope Flags - No extra scope/
], ],
[ / Security Results: 1 Result / [ / Security Results: 1 Result /
[1, h'689b98e649ae3b554e98aa2ae8f801eb'] / Payload Auth. Tag / [1, h'da08f4d8936024ad7c6b3b800e73dd97'] / Payload Auth. Tag /
] ]
Figure 10: Example 2: BCB Abstract Security Block (CBOR Diagnostic Figure 10: Example 2: BCB Abstract Security Block (CBOR Diagnostic
Notation) Notation)
The CBOR encoding of the BCB block-type-specific-data field (the The CBOR encoding of the BCB block-type-specific-data field (the
abstract security block) is 0x8101020182028202018482014c5477656c76653 abstract security block) is 0x8101020182028202018482014c5477656c76653
132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fa 132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fa
e70082040081820150689b98e649ae3b554e98aa2ae8f801eb. e70082040081820150da08f4d8936024ad7c6b3b800e73dd97.
A.2.3.3. Representations A.2.3.3. Representations
The BCB wrapping this abstract security block is as follows. The BCB wrapping this abstract security block is as follows.
[ [
12, / type code / 12, / type code /
2, / block number / 2, / block number /
1, / flags - block must be replicated in every fragment / 1, / flags - block must be replicated in every fragment /
0, / CRC type / 0, / CRC type /
h'8101020182028202018482014c5477656c766531323132313282020182035818 h'8101020182028202018482014c5477656c766531323132313282020182035818
69c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008182015068 69c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da
9b98e649ae3b554e98aa2ae8f801eb' 08f4d8936024ad7c6b3b800e73dd97'
] ]
Figure 11: Example 2: BCB (CBOR Diagnostic Notation) Figure 11: Example 2: BCB (CBOR Diagnostic Notation)
The CBOR encoding of the BCB block is 0x850c020100584f810102018202820 The CBOR encoding of the BCB block is 0x850c020100584f810102018202820
2018482014c5477656c76653132313231328202018203581869c411276fecddc4780d 2018482014c5477656c76653132313231328202018203581869c411276fecddc4780d
f42c8a2af89296fabf34d7fae70082040081820150689b98e649ae3b554e98aa2ae8f f42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e7
801eb. 3dd97.
A.2.4. Final Bundle A.2.4. Final Bundle
The CBOR encoding of the full output bundle, with the BCB: 0x9f880700 The CBOR encoding of the full output bundle, with the BCB: 0x9f880700
00820282010282028202018202820201820018281a000f4240850c020100584f81010 00820282010282028202018202820201820018281a000f4240850c020100584f81010
20182028202018482014c5477656c76653132313231328202018203581869c411276f 20182028202018482014c5477656c76653132313231328202018203581869c411276f
ecddc4780df42c8a2af89296fabf34d7fae70082040081820150689b98e649ae3b554 ecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7
e98aa2ae8f801eb850101000058203a09c1e63fe2097528a78b7c12943354a563e326 c6b3b800e73dd97850101000058203a09c1e63fe2097528a78b7c12943354a563e326
48b700c2784e26a990d91f9dff. 48b700c2784e26a990d91f9dff.
A.3. Example 3: Security Blocks from Multiple Sources A.3. Example 3: Security Blocks from Multiple Sources
This example shows the addition of a BIB and BCB to a sample bundle. This example shows the addition of a BIB and BCB to a sample bundle.
These two security blocks are added by two different nodes. The BCB These two security blocks are added by two different nodes. The BCB
is added by the source endpoint and the BIB is added by a forwarding is added by the source endpoint and the BIB is added by a forwarding
node. node.
The resulting bundle contains a BCB to encrypt the Payload Block and The resulting bundle contains a BCB to encrypt the Payload Block and
skipping to change at page 39, line 36 skipping to change at page 43, line 12
The following diagram shows the original bundle before the security The following diagram shows the original bundle before the security
blocks have been added. blocks have been added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Extension Block: Bundle Age Block | 7 | 2 | | Extension Block: Bundle Age Block | 7 | 2 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block | 0 | 1 | | Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 12: Example 3 Original Bundle Figure 12: Example 3 Original Bundle
A.3.1.1. Primary Block A.3.1.1. Primary Block
The primary block used in this example is identical to the primary The primary block used in this example is identical to the primary
block presented in Example 1 Appendix A.1.1.1. block presented in Example 1 Appendix A.1.1.1.
In summary, the CBOR encoding of the primary block is In summary, the CBOR encoding of the primary block is
skipping to change at page 41, line 31 skipping to change at page 44, line 49
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Integrity Block | 11 | 3 | | Bundle Integrity Block | 11 | 3 |
| OP(bib-integrity, targets=0, 2) | | | | OP(bib-integrity, targets=0, 2) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Confidentiality Block | 12 | 4 | | Bundle Confidentiality Block | 12 | 4 |
| OP(bcb-confidentiality, target=1) | | | | OP(bcb-confidentiality, target=1) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Extension Block: Bundle Age Block | 7 | 2 | | Extension Block: Bundle Age Block | 7 | 2 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 0 | 1 | | Payload Block (Encrypted) | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 14: Example 3 Resulting Bundle Figure 14: Example 3 Resulting Bundle
A.3.3. Bundle Integrity Block A.3.3. Bundle Integrity Block
In this example, a BIB is used to carry an integrity signature over In this example, a BIB is used to carry an integrity signature over
the bundle age block and an additional signature over the payload the bundle age block and an additional signature over the payload
block. The BIB is added by a waypoint node, ipn:3.0. block. The BIB is added by a waypoint node, ipn:3.0.
skipping to change at page 42, line 7 skipping to change at page 45, line 22
For this example, the following configuration and security parameters For this example, the following configuration and security parameters
are used to generate the security results indicated. are used to generate the security results indicated.
This BIB has two security targets and includes two security results, This BIB has two security targets and includes two security results,
holding the calculated signatures over the bundle age block and holding the calculated signatures over the bundle age block and
primary block. primary block.
Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
SHA Variant: HMAC 256/256 SHA Variant: HMAC 256/256
Scope Flags: 0 Scope Flags: h'00'
Primary Block Data: h'8807000082028201028202820201820282020182001 Primary Block Data: h'88070000820282010282028202018202
8281a000f4240' 820201820018281a000f4240'
Bundle Age Block Bundle Age Block
Data: h'85070200004319012c' Data: h'85070200004319012c'
Primary Block Primary Block
Signature: h'2f74b42d88234f0a8a98a6c72775ec6511aff3cb5bf Signature: h'8e059b8e71f7218264185a666bf3e453
c06aa648f5fc40f31ec0d' 076f2b883f4dce9b3cdb6464ed0dcf0f'
Bundle Age Block Bundle Age Block
Signature: h'e61385353ce2b4cce5319bc33326cdc26f4061e76cb Signature: h'72dee8eba049a22978e84a95d0496466
21b434c89199a36b00de3' 8eb131b1ca4800c114206d70d9065c80'
Figure 15: Example 3: Configuration, Parameters, and Results for the Figure 15: Example 3: Configuration, Parameters, and Results for the
BIB BIB
A.3.3.2. Abstract Security Block A.3.3.2. Abstract Security Block
The abstract security block structure of the BIB's block-type- The abstract security block structure of the BIB's block-type-
specific-data field for this application is as follows. specific-data field for this application is as follows.
[0, 2], / Security Target / [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/256 /
[3, 0] / Scope Flags - No Additional Scope / [3, h'00'] / Scope Flags - No Additional Scope /
], ],
[ / Security Results: 2 Results / [ / Security Results: 2 Results /
[1, h'2f74b42d88234f0a8a98a6c72775ec6511aff3 / Primary Block / [1, h'8e059b8e71f7218264185a666bf3e453
cb5bfc06aa648f5fc40f31ec0d'], 076f2b883f4dce9b3cdb6464ed0dcf0f'], / Primary Block /
[1, h'e61385353ce2b4cce5319bc33326cdc26f4061 / Bundle Age Block / [1, h'72dee8eba049a22978e84a95d0496466
e76cb21b434c89199a36b00de3'] 8eb131b1ca4800c114206d70d9065c80'] / Bundle Age Block /
] ]
Figure 16: Example 3: BIB Abstract Security Block (CBOR Diagnostic Figure 16: Example 3: BIB Abstract Security Block (CBOR Diagnostic
Notation) Notation)
The CBOR encoding of the BIB block-type-specific-data field (the The CBOR encoding of the BIB block-type-specific-data field (the
abstract security block) is 0x820002010182028203008282010582030082820 abstract security block) is 0x820002010182028203008282010582030082820
158202f74b42d88234f0a8a98a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d 158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f
82015820e61385353ce2b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00 8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065
de3. c80.
A.3.3.3. Representations A.3.3.3. Representations
The BIB wrapping this abstract security block is as follows. The BIB wrapping this abstract security block is as follows.
[ [
11, / type code / 11, / type code /
3, / block number / 3, / block number /
0, / flags / 0, / flags /
0, / CRC type / 0, / CRC type /
h'820002010182028203008282010582030082820158202f74b42d88234f0a8a98 h'820002010182028203008282010582030082820158208e059b8e71f721826418
a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d82015820e61385353ce2 5a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049
b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00de3', a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80',
] ]
Figure 17: Example 3: BIB (CBOR Diagnostic Notation) Figure 17: Example 3: BIB (CBOR Diagnostic Notation)
The CBOR encoding of the BIB block is 0x850b030000585a820002010182028 The CBOR encoding of the BIB block is 0x850b030000585a820002010182028
203008282010582030082820158202f74b42d88234f0a8a98a6c72775ec6511aff3cb 203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b88
5bfc06aa648f5fc40f31ec0d82015820e61385353ce2b4cce5319bc33326cdc26f406 3f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb13
1e76cb21b434c89199a36b00de3. 1b1ca4800c114206d70d9065c80.
A.3.4. Bundle Confidentiality Block A.3.4. Bundle Confidentiality Block
In this example, a BCB is used encrypt the payload block. The BCB is In this example, a BCB is used encrypt the payload block. The BCB is
added by the bundle source node, ipn:2.1. added by the bundle source node, ipn:2.1.
A.3.4.1. Configuration, Parameters, and Results A.3.4.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters For this example, the following configuration and security parameters
are used to generate the security results indicated. are used to generate the security results indicated.
This BCB has a single target, the payload block. Two security This BCB has a single target, the payload block. Two security
results are generated: cipher text which replaces the plain text results are generated: cipher text which replaces the plain text
block-type-specific data to encrypt the payload block, and an block-type-specific data to encrypt the payload block, and an
authentication tag. authentication tag.
Content Encryption Content Encryption
Key: h'71776572747975696f70617364666768' Key: h'71776572747975696f70617364666768'
IV: h'5477656c7665313231323132' IV: h'5477656c7665313231323132'
AES Variant: A128GCM AES Variant: A128GCM
Scope Flags: 0 Scope Flags: h'00'
Payload Data: h'52656164792047656e65726174652061 Payload Data: h'52656164792047656e65726174652061
2033322062797465207061796c6f6164' 2033322062797465207061796c6f6164'
Authentication Tag: h'689b98e649ae3b554e98aa2ae8f801eb' Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97'
Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354
a563e32648b700c2784e26a990d91f9d' a563e32648b700c2784e26a990d91f9d'
Figure 18: Example 3: Configuration, Parameters, and Results for the Figure 18: Example 3: Configuration, Parameters, and Results for the
BCB BCB
A.3.4.2. Abstract Security Block A.3.4.2. Abstract Security Block
The abstract security block structure of the BCB's block-type- The abstract security block structure of the BCB's block-type-
specific-data field for this application is as follows. specific-data field for this application is as follows.
[1], / Security Target / [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, b'Twelve121212'] / Initialization Vector /, [1, h'5477656c7665313231323132'], / Initialization Vector /
[2, 1] / AES Variant - AES 128 /, [2, 1], / AES Variant - AES 128 /
[4, 0] / Scope Flags - No Additional Scope / [4, h'00'] / Scope Flags - No Additional Scope /
], ],
[ / Security Results: 1 Result / [ / Security Results: 1 Result /
[1, h'689b98e649ae3b554e98aa2ae8f801eb'] / Payload Auth. Tag / [1, h'da08f4d8936024ad7c6b3b800e73dd97'] / Payload Auth. Tag /
] ]
Figure 19: Example 3: BCB Abstract Security Block (CBOR Diagnostic Figure 19: Example 3: BCB Abstract Security Block (CBOR Diagnostic
Notation) Notation)
The CBOR encoding of the BCB block-type-specific-data field (the The CBOR encoding of the BCB block-type-specific-data field (the
abstract security block) is 0x8101020182028202018382014c5477656C76653 abstract security block) is 0x8101020182028202018382014c5477656c76653
1323132313282020182040081820150689b98e649ae3b554e98aa2ae8f801eb. 1323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd97.
A.3.4.3. Representations A.3.4.3. Representations
The BCB wrapping this abstract security block is as follows. The BCB wrapping this abstract security block is as follows.
[ [
12, / type code / 12, / type code /
4, / block number / 4, / block number /
1, / flags - block must be replicated in every fragment / 1, / flags - block must be replicated in every fragment /
0, / CRC type / 0, / CRC type /
h'8101020182028202018382014c5477656C766531323132313282020182040081 h'8101020182028202018382014c5477656c766531323132313282020182040081
820150689b98e649ae3b554e98aa2ae8f801eb', 820150da08f4d8936024ad7c6b3b800e73dd97',
] ]
Figure 20: Example 3: BCB (CBOR Diagnostic Notation) Figure 20: Example 3: BCB (CBOR Diagnostic Notation)
The CBOR encoding of the BCB block is 0x850c0401005833810102018202820 The CBOR encoding of the BCB block is 0x850c0401005833810102018202820
2018382014c5477656C766531323132313282020182040081820150689b98e649ae3b 2018382014c5477656c766531323132313282020182040081820150da08f4d8936024
554e98aa2ae8f801eb. ad7c6b3b800e73dd97.
A.3.5. Final Bundle A.3.5. Final Bundle
The CBOR encoding of the full output bundle, with the BIB and BCB The CBOR encoding of the full output bundle, with the BIB and BCB
added is: 9F88070000820282010282028202018202820201820018281a000f42408 added is: 0x9f88070000820282010282028202018202820201820018281a000f424
50b030000585a820002010182028203008282010582030082820158202f74b42d8823 0850b030000585a820002010182028203008282010582030082820158208e059b8e71
4f0a8a98a6c72775ec6511aff3cb5bfc06aa648f5fc40f31ec0d82015820e61385353 f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8e
ce2b4cce5319bc33326cdc26f4061e76cb21b434c89199a36b00de3850c0401005833 ba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80850c04010058
8101020182028202018382014c5477656C76653132313231328202018204008182015 338101020182028202018382014c5477656c766531323132313282020182040081820
0689b98e649ae3b554e98aa2ae8f801eb85070200004319012c850101000058203a09 150da08f4d8936024ad7c6b3b800e73dd9785070200004319012c850101000058203a
c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dFF. 09c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff.
A.4. Example 4: Security Blocks with Full Scope A.4. Example 4: Security Blocks with Full Scope
This example shows the addition of a BIB and BCB to a sample bundle. This example shows the addition of a BIB and BCB to a sample bundle.
A BIB is added to provide integrity over the payload block and a BCB A BIB is added to provide integrity over the payload block and a BCB
is added for confidentiality over the payload and BIB. is added for confidentiality over the payload and BIB.
The integrity scope and additional authentication data will bind the The integrity scope and additional authentication data will bind the
primary block, target header, and the security header. primary block, target header, and the security header.
A.4.1. Original Bundle A.4.1. Original Bundle
The following diagram shows the original bundle before the security The following diagram shows the original bundle before the security
blocks have been added. blocks have been added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block | 0 | 1 | | Payload Block | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 21: Example 4 Original Bundle Figure 21: Example 4 Original Bundle
A.4.1.1. Primary Block A.4.1.1. Primary Block
The primary block used in this example is identical to the primary The primary block used in this example is identical to the primary
block presented in Example 1 Appendix A.1.1.1. block presented in Example 1 Appendix A.1.1.1.
In summary, the CBOR encoding of the primary block is In summary, the CBOR encoding of the primary block is
skipping to change at page 47, line 13 skipping to change at page 50, line 30
blocks are added. blocks are added.
Block Block Block Block Block Block
in Bundle Type Number in Bundle Type Number
+========================================+=======+========+ +========================================+=======+========+
| Primary Block | N/A | 0 | | Primary Block | N/A | 0 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Integrity Block (Encrypted) | 11 | 3 | | Bundle Integrity Block (Encrypted) | 11 | 3 |
| OP(bib-integrity, target=1) | | | | OP(bib-integrity, target=1) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Bundle Confidentiality Block | 12 | 4 | | Bundle Confidentiality Block | 12 | 2 |
| OP(bcb-confidentiality, targets=1, 3) | | | | OP(bcb-confidentiality, targets=1, 3) | | |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
| Payload Block (Encrypted) | 0 | 1 | | Payload Block (Encrypted) | 1 | 1 |
+----------------------------------------+-------+--------+ +----------------------------------------+-------+--------+
Figure 22: Example 4 Resulting Bundle Figure 22: Example 4 Resulting Bundle
A.4.3. Bundle Integrity Block A.4.3. Bundle Integrity Block
In this example, a BIB is used to carry an integrity signature over In this example, a BIB is used to carry an integrity signature over
the payload block. The IPPT contains the payload block block-type- the payload block. The IPPT contains the payload block block-type-
specific data, primary block data, the payload block header, and the specific data, primary block data, the payload block header, and the
BIB header. That is, all additional headers are included in the BIB header. That is, all additional headers are included in the
skipping to change at page 47, line 39 skipping to change at page 51, line 7
A.4.3.1. Configuration, Parameters, and Results A.4.3.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters For this example, the following configuration and security parameters
are used to generate the security results indicated. are used to generate the security results indicated.
This BIB has a single target and includes a single security result: This BIB has a single target and includes a single security result:
the calculated signature over the Payload block. the calculated signature over the Payload block.
Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b' Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
SHA Variant: HMAC 384/384 SHA Variant: HMAC 384/384
Scope Flags: 7 (all additional headers) Scope Flags: h'07' (all additional headers)
Primary Block Data: h'88070000820282010282028202018202 Primary Block Data: h'88070000820282010282028202018202
820201820018281a000f4240 820201820018281a000f4240
Payload Data: h'52656164792047656e65726174652061 Payload Data: h'52656164792047656e65726174652061
2033322062797465207061796c6f6164' 2033322062797465207061796c6f6164'
Payload Header: h'85010100005820' Payload Header: h'85010100005820'
BIB Header: h'850b0300005845' BIB Header: h'850b0300005845'
Payload Signature: h'6f56e0f58ec584df34603c75cc055939 Payload Signature: h'07c84d929f83bee4690130729d77a1bd
00b1a938f23883f119772e1230441d86 da9611cd6598e73d0659073ea74e8c27
9bce6ac9559f721260314424ab14b981 523b02193cb8ba64be58dbc556887aca
Figure 23: Example 4: Configuration, Parameters, and Results for the Figure 23: Example 4: Configuration, Parameters, and Results for the
BIB BIB
A.4.3.2. Abstract Security Block A.4.3.2. Abstract Security Block
The abstract security block structure of the BIB's block-type- The abstract security block structure of the BIB's block-type-
specific-data field for this application is as follows. specific-data field for this application is as follows.
[1], / Security Target / [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, 7] / Scope Flags - All additional headers in the SHA Hash / [3, h'07'] / Scope Flags - All additional headers in the SHA Hash /
], ],
[ / Security Results: 1 Result / [ / Security Results: 1 Result /
[1, h'6f56e0f58ec584df34603c75cc05593900b1a938f23883f119772e123044 [1, h'07c84d929f83bee4690130729d77a1bdda9611cd6598e73d
1d869bce6ac9559f721260314424ab14b981'] 0659073ea74e8c27523b02193cb8ba64be58dbc556887aca']
] ]
Figure 24: Example 4: BIB Abstract Security Block (CBOR Diagnostic Figure 24: Example 4: BIB Abstract Security Block (CBOR Diagnostic
Notation) Notation)
The CBOR encoding of the BIB block-type-specific-data field (the The CBOR encoding of the BIB block-type-specific-data field (the
abstract security block) is 0x810101018202820201828201068203078182015 abstract security block) is 0x810101018202820201828201068203078182015
8306f56e0f58ec584df34603c75cc05593900b1a938f23883f119772e1230441d869b 83007c84d929f83bee4690130729d77a1bdda9611cd6598e73d0659073ea74e8c2752
ce6ac9559f721260314424ab14b981. 3b02193cb8ba64be58dbc556887aca.
A.4.3.3. Representations A.4.3.3. Representations
The BIB wrapping this abstract security block is as follows. The BIB wrapping this abstract security block is as follows.
[ [
11, / type code / 11, / type code /
3, / block number / 3, / block number /
0, / flags / 0, / flags /
0, / CRC type / 0, / CRC type /
h'8101010182028202018282010682030781820158306f56e0f58ec584df34603c h'81010101820282020182820106820307818201583007c84d929f83bee4690130
75cc05593900b1a938f23883f119772e1230441d869bce6ac9559f7212603144 729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58db
24ab14b981', c556887aca',
] ]
Figure 25: Example 4: BIB (CBOR Diagnostic Notation) Figure 25: Example 4: BIB (CBOR Diagnostic Notation)
The CBOR encoding of the BIB block is 0x850b0300005845810101018202820 The CBOR encoding of the BIB block is 0x850b0300005845810101018202820
2018282010682030781820158306f56e0f58ec584df34603c75cc05593900b1a938f2 20182820106820307818201583007c84d929f83bee4690130729d77a1bdda9611cd65
3883f119772e1230441d869bce6ac9559f721260314424ab14b981. 98e73d0659073ea74e8c27523b02193cb8ba64be58dbc556887aca.
A.4.4. Bundle Confidentiality Block A.4.4. Bundle Confidentiality Block
In this example, a BCB is used encrypt the payload block and the BIB In this example, a BCB is used encrypt the payload block and the BIB
that provides integrity over the payload. that provides integrity over the payload.
A.4.4.1. Configuration, Parameters, and Results A.4.4.1. Configuration, Parameters, and Results
For this example, the following configuration and security parameters For this example, the following configuration and security parameters
are used to generate the security results indicated. are used to generate the security results indicated.
This BCB has two targets: the payload block and BIB. Four security This BCB has two targets: the payload block and BIB. Four security
results are generated: cipher text which replaces the plain text results are generated: cipher text which replaces the plain text
block-type-specific data of the payload block, cipher text to encrypt block-type-specific data of the payload block, cipher text to encrypt
the BIB, and authentication tags for both the payload block and BIB. the BIB, and authentication tags for both the payload block and BIB.
Key: h'71776572747975696f70617364666768 Key: h'71776572747975696f70617364666768
71776572747975696f70617364666768' 71776572747975696f70617364666768'
IV: h'5477656c7665313231323132' IV: h'5477656c7665313231323132'
AES Variant: A256GCM AES Variant: A256GCM
Scope Flags: 7 (All additional headers) Scope Flags: h'07' (All additional headers)
Payload Data: h'52656164792047656e65726174652061 Payload Data: h'52656164792047656e65726174652061
2033322062797465207061796c6f6164' 2033322062797465207061796c6f6164'
BIB Data: h'52656164792047656E65726174652061 BIB Data: h'81010101820282020182820106820307
2033322062797465207061796C6F6164' 818201583007c84d929f83bee4690130
729d77a1bdda9611cd6598e73d065907
3ea74e8c27523b02193cb8ba64be58db
c556887aca
BIB BIB
Authentication Tag: h'92bc2665e9f04350c5974f023929dd62' Authentication Tag: h'c95ed4534769b046d716e1cdfd00830e'
Payload Block Payload Block
Authentication Tag: h'865bc14b3910d6c53e95fdc65aa601fd' Authentication Tag: h'0e365c700e4bb19c0d991faff5345aff'
Payload Ciphertext: h'90eab64575930498d6aa654107f15e96 Payload Ciphertext: h'90eab64575930498d6aa654107f15e96
319bb227706000abc8fcac3b9bb9c87e' 319bb227706000abc8fcac3b9bb9c87e'
BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0 BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0
902a815f2276222e1d0208c628e2c926 902a815f221ebc837a134efc13bfa82a
2a0c438fc300190dbf5954ae4f84f748 2d5d317747da3eb54acef4ca839bd961
64e58ed1e39043633142ad2559e0e3a9 487284404259b60be12b8aed2f3e8a36
c9cbce5c2d' 2836529f66'
Figure 26: Example 4: Configuration, Parameters, and Results for the Figure 26: Example 4: Configuration, Parameters, and Results for the
BCB BCB
A.4.4.2. Abstract Security Block A.4.4.2. Abstract Security Block
The abstract security block structure of the BCB's block-type- The abstract security block structure of the BCB's block-type-
specific-data field for this application is as follows. specific-data field for this application is as follows.
[3, 1], / Security Target / [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, 7] / Scope Flags - All headers in SHA hash / [4, h'07'] / Scope Flags - All headers in SHA hash /
], ],
[ / Security Results: 2 Results / [ / Security Results: 2 Results /
[1, h'865bc14b3910d6c53e95fdc65aa601fd'], / Payload Auth. Tag / [1, h'c95ed4534769b046d716e1cdfd00830e'], / BIB Auth. Tag /
[1, h'92bc2665e9f04350c5974f023929dd62'] / BIB Auth. Tag / [1, h'0e365c700e4bb19c0d991faff5345aff'] / Payload Auth. Tag /
] ]
Figure 27: Example 4: BCB Abstract Security Block (CBOR Diagnostic Figure 27: Example 4: BCB Abstract Security Block (CBOR Diagnostic
Notation) Notation)
The CBOR encoding of the BCB block-type-specific-data field (the The CBOR encoding of the BCB block-type-specific-data field (the
abstract security block) is 0x820301020182028202018382014c5477656C766 abstract security block) is 0x820301020182028202018382014c5477656c766
531323132313282020382040782820150d0b506cc2e5ede57b36e6c52791457008201 531323132313282020382040782820150c95ed4534769b046d716e1cdfd00830e8201
50865bc14b3910d6c53e95fdc65aa601fd. 500e365c700e4bb19c0d991faff5345aff.
A.4.4.3. Representations A.4.4.3. Representations
The BCB wrapping this abstract security block is as follows. The BCB wrapping this abstract security block is as follows.
[ [
12, / type code / 12, / type code /
2, / block number / 2, / block number /
1, / flags - block must be replicated in every fragment / 1, / flags - block must be replicated in every fragment /
0, / CRC type / 0, / CRC type /
h'820301020182028202018382014c5477656C7665313231323132820203820407 h'820301020182028202018382014c5477656c7665313231323132820203820407
82820150d0b506cc2e5ede57b36e6c5279145700820150865bc14b3910d6c53e 82820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d
95fdc65aa601fd', 991faff5345aff',
] ]
Figure 28: Example 4: BCB (CBOR Diagnostic Notation) Figure 28: Example 4: BCB (CBOR Diagnostic Notation)
The CBOR encoding of the BCB block is 0x850c0201005847820301020182028 The CBOR encoding of the BCB block is 0x850c0201005847820301020182028
202018382014c5477656C766531323132313282020382040782820150d0b506cc2e5e 202018382014c5477656c766531323132313282020382040782820150c95ed4534769
de57b36e6c5279145700820150865bc14b3910d6c53e95fdc65aa601fd. b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff.
A.4.5. Final Bundle A.4.5. Final Bundle
The CBOR encoding of the full output bundle, with the security blocks The CBOR encoding of the full output bundle, with the security blocks
added and payload block and BIB encrypted is: 9F880700008202820102820 added and payload block and BIB encrypted is: 0x9f8807000082028201028
28202018202820201820018281a000f4240850b0300005845438ed6208eb1c1ffb94d 2028202018202820201820018281a000f4240850b0300005845438ed6208eb1c1ffb9
952175167df0902a815f2276222e1d0208c628e2c9262a0c438fc300190dbf5954ae4 4d952175167df0902a815f221ebc837a134efc13bfa82a2d5d317747da3eb54acef4c
f84f74864e58ed1e39043633142ad2559e0e3a9c9cbce5c2d 850c020100584782030 a839bd961487284404259b60be12b8aed2f3e8a362836529f66 850c0201005847820
1020182028202018382014c5477656C766531323132313282020382040782820150d0 301020182028202018382014c5477656c766531323132313282020382040782820150
b506cc2e5ede57b36e6c5279145700820150865bc14b3910d6c53e95fdc65aa601fd8 c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345af
501010000582090eab64575930498d6aa654107f15e96319bb227706000abc8fcac3b f8501010000582090eab64575930498d6aa654107f15e96319bb227706000abc8fcac
9bb9c87eFF. 3b9bb9c87eff.
Appendix B. Acknowledgements Appendix B. Acknowledgements
The following participants contributed useful review and analysis of Amy Alford of the Johns Hopkins University Applied Physics Laboratory
these security contexts: Amy Alford of the Johns Hopkins University contributed useful review and analysis of these security contexts.
Applied Physics Laboratory.
Authors' Addresses 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
 End of changes. 139 change blocks. 
400 lines changed or deleted 561 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/