draft-ietf-dtn-bpsec-13.txt   draft-ietf-dtn-bpsec-14.txt 
Delay-Tolerant Networking E. Birrane Delay-Tolerant Networking E. Birrane
Internet-Draft K. McKeever Internet-Draft K. McKeever
Intended status: Standards Track JHU/APL Obsoletes: 6257 (if approved) JHU/APL
Expires: May 7, 2020 November 4, 2019 Intended status: Standards Track January 16, 2020
Expires: July 19, 2020
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-13 draft-ietf-dtn-bpsec-14
Abstract Abstract
This document defines a security protocol providing end to end data This document defines a security protocol providing end to end data
integrity and confidentiality services for the Bundle Protocol. integrity and confidentiality services for the Bundle Protocol.
The Internet Research Task Force is advised that this document is an
update of the protocol described in [RFC6257], reflecting lessons
learned. The Internet Research Task Force is requested to mark
[RFC6257] as obsolete.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 7, 2020. This Internet-Draft will expire on July 19, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Supported Security Services . . . . . . . . . . . . . . . 3 1.1. Supported Security Services . . . . . . . . . . . . . . . 4
1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4 1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4
1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5 1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 7 2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 7 2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 7
2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8 2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8
2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8
2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9
2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9
3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 10
3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11
3.4. Target Identification . . . . . . . . . . . . . . . . . . 11 3.4. Target Identification . . . . . . . . . . . . . . . . . . 12
3.5. Block Representation . . . . . . . . . . . . . . . . . . 12 3.5. Block Representation . . . . . . . . . . . . . . . . . . 12
3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12
3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15
3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16
3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17
3.10. Parameter and Result Identification . . . . . . . . . . . 18 3.10. Parameter and Result Identification . . . . . . . . . . . 18
3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 19 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 19
3.11.1. Example 1: Constructing a Bundle with Security . . . 19 3.11.1. Example 1: Constructing a Bundle with Security . . . 19
3.11.2. Example 2: Adding More Security At A New Node . . . 20 3.11.2. Example 2: Adding More Security At A New Node . . . 20
4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 20
5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 21
5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 21
5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 21
5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 22
5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 25 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 23
6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 25 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 24
7. Security Policy Considerations . . . . . . . . . . . . . . . 25 7. Security Policy Considerations . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8.1. Attacker Capabilities and Objectives . . . . . . . . . . 27 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 26
8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 28 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 27
8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 28 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 27
8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 27
8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 28
8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 30 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 29
9. Security Context Considerations . . . . . . . . . . . . . . . 31 9. Security Context Considerations . . . . . . . . . . . . . . . 29
9.1. Identification and Configuration . . . . . . . . . . . . 31 9.1. Identification and Configuration . . . . . . . . . . . . 29
9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 31 9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 30
10. Defining Other Security Blocks . . . . . . . . . . . . . . . 33 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 32
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 34 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 33
11.2. Security Context Identifiers . . . . . . . . . . . . . . 34 11.2. Security Context Identifiers . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 35 12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 35 12.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This document defines security features for the Bundle Protocol (BP) This document defines security features for the Bundle Protocol (BP)
[I-D.ietf-dtn-bpbis] and is intended for use in Delay Tolerant [I-D.ietf-dtn-bpbis] and is intended for use in Delay Tolerant
Networks (DTNs) to provide end-to-end security services. Networks (DTNs) to provide end-to-end security services.
The Bundle Protocol specification [I-D.ietf-dtn-bpbis] defines DTN as The Bundle Protocol specification [I-D.ietf-dtn-bpbis] defines DTN as
referring to "a networking architecture providing communications in referring to "a networking architecture providing communications in
and/or through highly stressed environments" where "BP may be viewed and/or through highly stressed environments" where "BP may be viewed
skipping to change at page 3, line 40 skipping to change at page 3, line 44
transport security mechanisms may not be sufficient. For example, transport security mechanisms may not be sufficient. For example,
the store-carry-forward nature of the network may require protecting the store-carry-forward nature of the network may require protecting
data at rest, preventing unauthorized consumption of critical data at rest, preventing unauthorized consumption of critical
resources such as storage space, and operating without regular resources such as storage space, and operating without regular
contact with a centralized security oracle (such as a certificate contact with a centralized security oracle (such as a certificate
authority). authority).
An end-to-end security service is needed that operates in all of the An end-to-end security service is needed that operates in all of the
environments where the BP operates. environments where the BP operates.
The Internet Research Task Force is advised that this document is an
update of the protocol described in [RFC6257], reflecting lessons
learned. The Internet Research Task Force is requested to mark
[RFC6257] as obsolete.
1.1. Supported Security Services 1.1. Supported Security Services
BPSec provides end-to-end integrity and confidentiality services for BPSec provides end-to-end integrity and confidentiality services for
BP bundles, as defined in this section. BP bundles, as defined in this section.
Integrity services ensure that changes to target data within a bundle Integrity services ensure that changes to target data within a bundle
can be discovered. Data changes may be caused by processing errors, can be discovered. Data changes may be caused by processing errors,
environmental conditions, or intentional manipulation. In the environmental conditions, or intentional manipulation. In the
context of BPSec, integrity services apply to plain-text in the context of BPSec, integrity services apply to plain-text in the
bundle. bundle.
skipping to change at page 6, line 26 skipping to change at page 6, line 39
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This section defines terminology either unique to the BPSec or This section defines terminology either unique to the BPSec or
otherwise necessary for understanding the concepts defined in this otherwise necessary for understanding the concepts defined in this
specification. specification.
o Bundle Destination - the node which receives a bundle and delivers o Bundle Destination - the node which receives a bundle and delivers
the payload of the bundle to an application. Also, the Node ID of the payload of the bundle to an application. Also, the Node ID of
the Bundle Protocol Agent (BPA) receiving the bundle. The bundle the Bundle Protocol Agent (BPA) receiving the bundle. The bundle
destination acts as the security destination for every security destination acts as the security acceptor for every security
target in every security block in every bundle it receives. target in every security block in every bundle it receives.
o Bundle Source - the node which originates a bundle. Also, the o Bundle Source - the node which originates a bundle. Also, the
Node ID of the BPA originating the bundle. Node ID of the BPA originating the bundle.
o Cipher Suite - a set of one or more algorithms providing integrity o Cipher Suite - a set of one or more algorithms providing integrity
and confidentiality services. Cipher suites may define necessary and confidentiality services. Cipher suites may define necessary
parameters but do not provide values for those parameters. parameters but do not provide values for those parameters.
o Forwarder - any node that transmits a bundle in the DTN. Also, o Forwarder - any node that transmits a bundle in the DTN. Also,
skipping to change at page 6, line 48 skipping to change at page 7, line 13
hop. hop.
o Intermediate Receiver, Waypoint, or Next Hop - any node that o Intermediate Receiver, Waypoint, or Next Hop - any node that
receives a bundle from a Forwarder that is not the Bundle receives a bundle from a Forwarder that is not the Bundle
Destination. Also, the Node ID of the BPA at any such node. Destination. Also, the Node ID of the BPA at any such node.
o Path - the ordered sequence of nodes through which a bundle passes o Path - the ordered sequence of nodes through which a bundle passes
on its way from Source to Destination. The path is not on its way from Source to Destination. The path is not
necessarily known in advance by the bundle or any BPAs in the DTN. necessarily known in advance by the bundle or any BPAs in the DTN.
o Security Acceptor - a bundle node that processes and dispositions
one or more security blocks in a bundle. Also, the Node ID of
that node.
o Security Block - a BPSec extension block in a bundle. o Security Block - a BPSec extension block in a bundle.
o Security Context - the set of assumptions, algorithms, o Security Context - the set of assumptions, algorithms,
configurations and policies used to implement security services. configurations and policies used to implement security services.
o Security Destination - a bundle node that processes one or more
security blocks in a bundle. Also, the Node ID of that node.
o Security Operation - the application of a security service to a o Security Operation - the application of a security service to a
security target, notated as OP(security service, security target). security target, notated as OP(security service, security target).
For example, OP(confidentiality, payload). Every security For example, OP(confidentiality, payload). Every security
operation in a bundle MUST be unique, meaning that a security operation in a bundle MUST be unique, meaning that a security
service can only be applied to a security target once in a bundle. service can only be applied to a security target once in a bundle.
A security operation is implemented by a security block. A security operation is implemented by a security block.
o Security Service - the security features supported by this o Security Service - the security features supported by this
specification: either integrity or confidentiality. specification: either integrity or confidentiality.
skipping to change at page 8, line 45 skipping to change at page 9, line 12
The security policy enforced by nodes in the DTN may differ. The security policy enforced by nodes in the DTN may differ.
Some waypoints might not be security aware and will not be able to Some waypoints might not be security aware and will not be able to
process security blocks. Therefore, security blocks must have their process security blocks. Therefore, security blocks must have their
processing flags set such that the block will be treated processing flags set such that the block will be treated
appropriately by non-security-aware waypoints. appropriately by non-security-aware waypoints.
Some waypoints will have security policies that require evaluating Some waypoints will have security policies that require evaluating
security services even if they are not the bundle destination or the security services even if they are not the bundle destination or the
final intended destination of the service. For example, a waypoint final intended acceptor of the service. For example, a waypoint
could choose to verify an integrity service even though the waypoint could choose to verify an integrity service even though the waypoint
is not the bundle destination and the integrity service will be is not the bundle destination and the integrity service will be
needed by other nodes along the bundle's path. needed by other nodes along the bundle's path.
Some waypoints will determine, through policy, that they are the Some waypoints will determine, through policy, that they are the
intended recipient of the security service and terminate the security intended recipient of the security service and terminate the security
service in the bundle. For example, a gateway node could determine service in the bundle. For example, a gateway node could determine
that, even though it is not the destination of the bundle, it should that, even though it is not the destination of the bundle, it should
verify and remove a particular integrity service or attempt to verify and remove a particular integrity service or attempt to
decrypt a confidentiality service, before forwarding the bundle along decrypt a confidentiality service, before forwarding the bundle along
skipping to change at page 11, line 41 skipping to change at page 12, line 4
When representing multiple security operations in a single security When representing multiple security operations in a single security
block, the information that is common across all operations is block, the information that is common across all operations is
represented once in the security block, and the information which is represented once in the security block, and the information which is
different (e.g., the security targets) are represented individually. different (e.g., the security targets) are represented individually.
It is RECOMMENDED that if a node processes any security operation in It is RECOMMENDED that if a node processes any security operation in
a security block that it process all security operations in the a security block that it process all security operations in the
security block. This allows security sources to assert that the set security block. This allows security sources to assert that the set
of security operations in a security block are expected to be of security operations in a security block are expected to be
processed by the same security destination. However, the processed by the same security acceptor. However, the determination
determination of whether a node actually is a security destination or of whether a node actually is a security acceptor or not is a matter
not is a matter of the policy of the node itself. In cases where a of the policy of the node itself. In cases where a receiving node
receiving node determines that it is the security destination of only determines that it is the security acceptor of only a subset of the
a subset of the security operations in a security block, the node may security operations in a security block, the node may choose to only
choose to only process that subset of security operations. process that subset of security operations.
3.4. Target Identification 3.4. Target Identification
A security target is a block in the bundle to which a security A security target is a block in the bundle to which a security
service applies. This target must be uniquely and unambiguously service applies. This target must be uniquely and unambiguously
identifiable when processing a security block. The definition of the identifiable when processing a security block. The definition of the
extension block header from [I-D.ietf-dtn-bpbis] provides a "Block extension block header from [I-D.ietf-dtn-bpbis] provides a "Block
Number" field suitable for this purpose. Therefore, a security Number" field suitable for this purpose. Therefore, a security
target in a security block MUST be represented as the Block Number of target in a security block MUST be represented as the Block Number of
the target block. the target block.
skipping to change at page 14, line 20 skipping to change at page 14, line 31
in Section 3.10. in Section 3.10.
* Parameter Value. This field captures the value associated * Parameter Value. This field captures the value associated
with this parameter. This field SHALL be represented by the with this parameter. This field SHALL be represented by the
applicable CBOR representation of the parameter, in applicable CBOR representation of the parameter, in
accordance with Section 3.10. accordance with Section 3.10.
The logical layout of the parameters array is illustrated in The logical layout of the parameters array is illustrated in
Figure 1. Figure 1.
+----------------+----------------+ +----------------+
| Parameter 1 | Parameter 2 | ... | Parameter N |
+------+---------+------+---------+ +------+---------+
| Id | Value | Id | Value | | Id | Value |
+------+---------+------+---------+ +------+---------+
Figure 1: Security Context Parameters Figure 1: Security Context Parameters
Security Results: Security Results:
This field captures the results of applying a security service This field captures the results of applying a security service
to the security targets of the security block. This field to the security targets of the security block. This field
SHALL be represented as a CBOR array of target results. Each SHALL be represented as a CBOR array of target results. Each
entry in this array represents the set of security results for entry in this array represents the set of security results for
a specific security target. The target results MUST be ordered a specific security target. The target results MUST be ordered
identically to the Security Targets field of the security identically to the Security Targets field of the security
block. This means that the first set of target results in this block. This means that the first set of target results in this
skipping to change at page 15, line 17 skipping to change at page 15, line 23
* Result Value. This field captures the value associated with * Result Value. This field captures the value associated with
the result. This field SHALL be represented by the the result. This field SHALL be represented by the
applicable CBOR representation of the result value, in applicable CBOR representation of the result value, in
accordance with Section 3.10. accordance with Section 3.10.
The logical layout of the security results array is illustrated The logical layout of the security results array is illustrated
in Figure 2. In this figure there are N security targets for in Figure 2. In this figure there are N security targets for
this security block. The first security target contains M this security block. The first security target contains M
results and the Nth security target contains K results. results and the Nth security target contains K results.
+------------------------------+ +------------------------------+
| Target 1 | | Target N |
+------------+----+------------+ +------------------------------+
| Result 1 | | Result M | ... | Result 1 | | Result K |
+----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+
| Id | Value | | Id | Value | | Id | Value | | Id | Value |
+----+-------+ +----+-------+ +----+-------+ +----+-------+
Figure 2: Security Results Figure 2: Security Results
3.7. Block Integrity Block 3.7. Block Integrity Block
A BIB is a bundle extension block with the following characteristics. A BIB is a bundle extension block with the following characteristics.
o The Block Type Code value is as specified in Section 11.1. o The Block Type Code value is as specified in Section 11.1.
o The Block Type Specific Data Fields follow the structure of the o The Block Type Specific Data Fields follow the structure of the
ASB. ASB.
o A security target listed in the Security Targets field MUST NOT o A security target listed in the Security Targets field MUST NOT
reference a security block defined in this specification (e.g., a reference a security block defined in this specification (e.g., a
BIB or a BCB). BIB or a BCB).
o The Security Context Id MUST utilize an end-to-end authentication o The Security Context Id MUST utilize an end-to-end authentication
cipher or an end-to-end error detection cipher. cipher or an end-to-end error detection cipher.
o An EID-reference to the security source MAY be present. If this o The EID of the security source MAY be present. If this field is
field is not present, then the security source of the block SHOULD not present, then the security source of the block SHOULD be
be inferred according to security policy and MAY default to the inferred according to security policy and MAY default to the
bundle source. The security source MAY be specified as part of bundle source. The security source MAY be specified as part of
security context information described in Section 3.10. security context information described in Section 3.10.
Notes: Notes:
o It is RECOMMENDED that designers carefully consider the effect of o It is RECOMMENDED that designers carefully consider the effect of
setting flags that either discard the block or delete the bundle setting flags that either discard the block or delete the bundle
in the event that this block cannot be processed. in the event that this block cannot be processed.
o Since OP(integrity, target) is allowed only once in a bundle per o Since OP(integrity, target) is allowed only once in a bundle per
target, it is RECOMMENDED that users wishing to support multiple target, it is RECOMMENDED that users wishing to support multiple
integrity signatures for the same target define a multi-signature integrity signatures for the same target define a multi-signature
security context. security context.
o For some security contexts, (e.g., those using asymmetric keying o For some security contexts, (e.g., those using asymmetric keying
to produce signatures or those using symmetric keying with a group to produce signatures or those using symmetric keying with a group
key), the security information MAY be checked at any hop on the key), the security information MAY be checked at any hop on the
way to the destination that has access to the required keying way to the bundle destination that has access to the required
information, in accordance with Section 3.9. keying information, in accordance with Section 3.9.
3.8. Block Confidentiality Block 3.8. Block Confidentiality Block
A BCB is a bundle extension block with the following characteristics. A BCB is a bundle extension block with the following characteristics.
The Block Type Code value is as specified in Section 11.1. The Block Type Code value is as specified in Section 11.1.
The Block Processing Control flags value can be set to whatever The Block Processing Control flags value can be set to whatever
values are required by local policy, except that this block MUST values are required by local policy, except that this block MUST
have the "replicate in every fragment" flag set if the target of have the "replicate in every fragment" flag set if the target of
skipping to change at page 16, line 50 skipping to change at page 16, line 46
The Security Context Id MUST utilize a confidentiality cipher that The Security Context Id MUST utilize a confidentiality cipher that
provides authenticated encryption with associated data (AEAD). provides authenticated encryption with associated data (AEAD).
Additional information created by a cipher suite (such as Additional information created by a cipher suite (such as
additional authenticated data) can be placed either in a security additional authenticated data) can be placed either in a security
result field or in the generated cipher-text. The determination result field or in the generated cipher-text. The determination
of where to place these data is a function of the cipher suite and of where to place these data is a function of the cipher suite and
security context used. security context used.
An EID-reference to the security source MAY be present. If this The EID of the security source MAY be present. If this field is
field is not present, then the security source of the block SHOULD not present, then the security source of the block SHOULD be
be inferred according to security policy and MAY default to the inferred according to security policy and MAY default to the
bundle source. The security source MAY be specified as part of bundle source. The security source MAY be specified as part of
security context information described in Section 3.10. security context information described in Section 3.10.
The BCB modifies the contents of its security target(s). When a BCB The BCB modifies the contents of its security target(s). When a BCB
is applied, the security target body data are encrypted "in-place". is applied, the security target body data are encrypted "in-place".
Following encryption, the security target Block Type Specific Data Following encryption, the security target Block Type Specific Data
field contains cipher-text, not plain-text. Other block fields field contains cipher-text, not plain-text. Other block fields
remain unmodified, with the exception of the Block Data Length field, remain unmodified, with the exception of the Block Data Length field,
which MUST be updated to reflect the new length of the Block Type which MUST be updated to reflect the new length of the Block Type
Specific Data field. Specific Data field.
skipping to change at page 18, line 36 skipping to change at page 18, line 33
security target. security target.
These restrictions on block interactions impose a necessary ordering These restrictions on block interactions impose a necessary ordering
when applying security operations within a bundle. Specifically, for when applying security operations within a bundle. Specifically, for
a given security target, BIBs MUST be added before BCBs. This a given security target, BIBs MUST be added before BCBs. This
ordering MUST be preserved in cases where the current BPA is adding ordering MUST be preserved in cases where the current BPA is adding
all of the security blocks for the bundle or whether the BPA is a all of the security blocks for the bundle or whether the BPA is a
waypoint adding new security blocks to a bundle that already contains waypoint adding new security blocks to a bundle that already contains
security blocks. security blocks.
NOTE: Since any cipher suite used with a BCB MUST be an AEAD cipher Since any cipher suite used with a BCB MUST be an AEAD cipher suite,
suite, it is inefficient and possibly insecure for a single security it is inefficient and insecure for a single security source to add
source to add both a BIB and a BCB for the same security target. In both a BIB and a BCB for the same security target. In cases where a
cases where a security source wishes to calculate both a plain-text security source wishes to calculate both a plain-text integrity
integrity mechanism and encrypt a security target, a BCB with a mechanism and encrypt a security target, a BCB with a security
security context that generates such signatures as additional context that generates such signatures as additional security results
security results SHOULD be used instead. MUST be used instead.
3.10. Parameter and Result Identification 3.10. Parameter and Result Identification
Each security context MUST define its own context parameters and Each security context MUST define its own context parameters and
results. Each defined parameter and result is represented as the results. Each defined parameter and result is represented as the
tuple of an identifier and a value. Identifiers are always tuple of an identifier and a value. Identifiers are always
represented as a CBOR unsigned integer. The CBOR encoding of values represented as a CBOR unsigned integer. The CBOR encoding of values
is as defined by the security context specification. is as defined by the security context specification.
Identifiers MUST be unique for a given security context but do not Identifiers MUST be unique for a given security context but do not
skipping to change at page 19, line 30 skipping to change at page 19, line 27
In this example a bundle has four non-security-related blocks: the In this example a bundle has four non-security-related blocks: the
primary block (B1), two extension blocks (B4,B5), and a payload block primary block (B1), two extension blocks (B4,B5), and a payload block
(B6). The bundle source wishes to provide an integrity signature of (B6). The bundle source wishes to provide an integrity signature of
the plain-text associated with the primary block, the second the plain-text associated with the primary block, the second
extension block, and the payload. The bundle source also wishes to extension block, and the payload. The bundle source also wishes to
provide confidentiality for the first extension block. The resultant provide confidentiality for the first extension block. The resultant
bundle is illustrated in Figure 3 and the security actions are bundle is illustrated in Figure 3 and the security actions are
described below. described below.
Block in Bundle ID
+======================================+====+
| Primary Block | B1 |
+--------------------------------------+----+
| BIB | B2 |
| OP(integrity, targets=B1, B5, B6) | |
+--------------------------------------+----+
| BCB | B3 |
| OP(confidentiality, target=B4) | |
+--------------------------------------+----+
| Extension Block (encrypted) | B4 |
+--------------------------------------+----+
| Extension Block | B5 |
+--------------------------------------+----+
| Payload Block | B6 |
+--------------------------------------+----+
Figure 3: Security at Bundle Creation Figure 3: Security at Bundle Creation
The following security actions were applied to this bundle at its The following security actions were applied to this bundle at its
time of creation. time of creation.
o An integrity signature applied to the canonicalized primary block o An integrity signature applied to the canonicalized primary block
(B1), the second extension block (B5) and the payload block (B6). (B1), the second extension block (B5) and the payload block (B6).
This is accomplished by a single BIB (B2) with multiple targets. This is accomplished by a single BIB (B2) with multiple targets.
A single BIB is used in this case because all three targets share A single BIB is used in this case because all three targets share
a security source, security context, and security context a security source, security context, and security context
skipping to change at page 21, line 5 skipping to change at page 20, line 19
extension block and the bundle payload. The waypoint security policy extension block and the bundle payload. The waypoint security policy
is to allow existing BIBs for these blocks to persist, as they may be is to allow existing BIBs for these blocks to persist, as they may be
required as part of the security policy at the bundle destination. required as part of the security policy at the bundle destination.
The resultant bundle is illustrated in Figure 4 and the security The resultant bundle is illustrated in Figure 4 and the security
actions are described below. Note that block IDs provided here are actions are described below. Note that block IDs provided here are
ordered solely for the purpose of this example and not meant to ordered solely for the purpose of this example and not meant to
impose an ordering for block creation. The ordering of blocks added impose an ordering for block creation. The ordering of blocks added
to a bundle MUST always be in compliance with [I-D.ietf-dtn-bpbis]. to a bundle MUST always be in compliance with [I-D.ietf-dtn-bpbis].
Block in Bundle ID
+======================================+====+
| Primary Block | B1 |
+--------------------------------------+----+
| BIB | B2 |
| OP(integrity, targets=B1) | |
+--------------------------------------+----+
| BIB (encrypted) | B7 |
| OP(integrity, targets=B5, B6) | |
+--------------------------------------+----+
| BCB | B8 |
| OP(confidentiality, target=B5,B6,B7) | |
+--------------------------------------+----+
| BCB | B3 |
| OP(confidentiality, target=B4) | |
+--------------------------------------+----+
| Extension Block (encrypted) | B4 |
+--------------------------------------+----+
| Extension Block (encrypted) | B5 |
+--------------------------------------+----+
| Payload Block (encrypted) | B6 |
+--------------------------------------+----+
Figure 4: Security At Bundle Forwarding Figure 4: Security At Bundle Forwarding
The following security actions were applied to this bundle prior to The following security actions were applied to this bundle prior to
its forwarding from the waypoint node. its forwarding from the waypoint node.
o Since the waypoint node wishes to encrypt blocks B5 and B6, it o Since the waypoint node wishes to encrypt blocks B5 and B6, it
MUST also encrypt the BIBs providing plain-text integrity over MUST also encrypt the BIBs providing plain-text integrity over
those blocks. However, BIB B2 could not be encrypted in its those blocks. However, BIB B2 could not be encrypted in its
entirety because it also held a signature for the primary block entirety because it also held a signature for the primary block
(B1). Therefore, a new BIB (B7) is created and security results (B1). Therefore, a new BIB (B7) is created and security results
skipping to change at page 23, line 16 skipping to change at page 21, line 51
Security blocks must be processed in a specific order when received Security blocks must be processed in a specific order when received
by a security-aware node. The processing order is as follows. by a security-aware node. The processing order is as follows.
o When BIBs and BCBs share a security target, BCBs MUST be evaluated o When BIBs and BCBs share a security target, BCBs MUST be evaluated
first and BIBs second. first and BIBs second.
5.1.1. Receiving BCBs 5.1.1. Receiving BCBs
If a received bundle contains a BCB, the receiving node MUST If a received bundle contains a BCB, the receiving node MUST
determine whether it is the security destination for any of the determine whether it is the security acceptor for any of the security
security operations in the BCB. If so, the node MUST process those operations in the BCB. If so, the node MUST process those operations
operations and remove any operation-specific information from the BCB and remove any operation-specific information from the BCB prior to
prior to delivering data to an application at the node or forwarding delivering data to an application at the node or forwarding the
the bundle. If processing a security operation fails, the target bundle. If processing a security operation fails, the target SHALL
SHALL be processed according to the security policy. A bundle status be processed according to the security policy. A bundle status
report indicating the failure MAY be generated. When all security report indicating the failure MAY be generated. When all security
operations for a BCB have been removed from the BCB, the BCB MUST be operations for a BCB have been removed from the BCB, the BCB MUST be
removed from the bundle. removed from the bundle.
If the receiving node is the destination of the bundle, the node MUST If the receiving node is the destination of the bundle, the node MUST
decrypt any BCBs remaining in the bundle. If the receiving node is decrypt any BCBs remaining in the bundle. If the receiving node is
not the destination of the bundle, the node MUST process the BCB if not the destination of the bundle, the node MUST process the BCB if
directed to do so as a matter of security policy. directed to do so as a matter of security policy.
If the security policy of a security-aware node specifies that a If the security policy of a security-aware node specifies that a
skipping to change at page 24, line 13 skipping to change at page 22, line 47
it MUST be updated to reflect the decrypted block length. it MUST be updated to reflect the decrypted block length.
If a BCB contains multiple security operations, each operation If a BCB contains multiple security operations, each operation
processed by the node MUST be be treated as if the security operation processed by the node MUST be be treated as if the security operation
has been represented by a single BCB with a single security operation has been represented by a single BCB with a single security operation
for the purposes of report generation and policy processing. for the purposes of report generation and policy processing.
5.1.2. Receiving BIBs 5.1.2. Receiving BIBs
If a received bundle contains a BIB, the receiving node MUST If a received bundle contains a BIB, the receiving node MUST
determine whether it is the security destination for any of the determine whether it is the security acceptor for any of the security
security operations in the BIB. If so, the node MUST process those operations in the BIB. If so, the node MUST process those operations
operations and remove any operation-specific information from the BIB and remove any operation-specific information from the BIB prior to
prior to delivering data to an application at the node or forwarding delivering data to an application at the node or forwarding the
the bundle. If processing a security operation fails, the target bundle. If processing a security operation fails, the target SHALL
SHALL be processed according to the security policy. A bundle status be processed according to the security policy. A bundle status
report indicating the failure MAY be generated. When all security report indicating the failure MAY be generated. When all security
operations for a BIB have been removed from the BIB, the BIB MUST be operations for a BIB have been removed from the BIB, the BIB MUST be
removed from the bundle. removed from the bundle.
A BIB MUST NOT be processed if the security target of the BIB is also A BIB MUST NOT be processed if the security target of the BIB is also
the security target of a BCB in the bundle. Given the order of the security target of a BCB in the bundle. Given the order of
operations mandated by this specification, when both a BIB and a BCB operations mandated by this specification, when both a BIB and a BCB
share a security target, it means that the security target must have share a security target, it means that the security target must have
been encrypted after it was integrity signed and, therefore, the BIB been encrypted after it was integrity signed and, therefore, the BIB
cannot be verified until the security target has been decrypted by cannot be verified until the security target has been decrypted by
skipping to change at page 24, line 41 skipping to change at page 23, line 27
If the security policy of a security-aware node specifies that a If the security policy of a security-aware node specifies that a
bundle should have applied integrity to a specific security target bundle should have applied integrity to a specific security target
and no such BIB is present in the bundle, then the node MUST process and no such BIB is present in the bundle, then the node MUST process
this security target in accordance with the security policy. This this security target in accordance with the security policy. This
may involve removing the security target from the bundle. If the may involve removing the security target from the bundle. If the
removed security target is the payload or primary block, the bundle removed security target is the payload or primary block, the bundle
MAY be discarded. This action can occur at any node that has the MAY be discarded. This action can occur at any node that has the
ability to verify an integrity signature, not just the bundle ability to verify an integrity signature, not just the bundle
destination. destination.
If a receiving node is not the security destination of a security If a receiving node is not the security acceptor of a security
operation in a BIB it MAY attempt to verify the security operation operation in a BIB it MAY attempt to verify the security operation
anyway to prevent forwarding corrupt data. If the verification anyway to prevent forwarding corrupt data. If the verification
fails, the node SHALL process the security target in accordance to fails, the node SHALL process the security target in accordance to
local security policy. It is RECOMMENDED that if a payload integrity local security policy. It is RECOMMENDED that if a payload integrity
check fails at a waypoint that it is processed in the same way as if check fails at a waypoint that it is processed in the same way as if
the check fails at the bundle destination. If the check passes, the the check fails at the bundle destination. If the check passes, the
node MUST NOT remove the security operation from the BIB prior to node MUST NOT remove the security operation from the BIB prior to
forwarding. forwarding.
If a BIB contains multiple security operations, each operation If a BIB contains multiple security operations, each operation
skipping to change at page 31, line 36 skipping to change at page 30, line 24
of contexts can be defined with each context supporting few, if any, of contexts can be defined with each context supporting few, if any,
parameters. parameters.
Security Context Examples Security Context Examples
+---------+------------+--------------------------------------------+ +---------+------------+--------------------------------------------+
| Context | Parameters | Definition | | Context | Parameters | Definition |
| Id | | | | Id | | |
+---------+------------+--------------------------------------------+ +---------+------------+--------------------------------------------+
| 1 | Key, IV | AES-GCM-256 cipher suite with provided | | 1 | Key, IV | AES-GCM-256 cipher suite with provided |
| | | ephemeral key and initialization vector. | | | | ephemeral key and |
| | | initialization vector. |
| 2 | IV | AES-GCM-256 cipher suite with | | 2 | IV | AES-GCM-256 cipher suite with |
| | | predetermined key and predetermined key | | | | predetermined key and predetermined |
| | | rotation policy. | | | | key rotation policy. |
| 3 | Nil | AES-GCM-256 cipher suite with all info | | 3 | Nil | AES-GCM-256 cipher suite with all info |
| | | predetermined. | | | | predetermined. |
+---------+------------+--------------------------------------------+ +---------+------------+--------------------------------------------+
Table 1 Table 1
9.2. Authorship 9.2. Authorship
Developers or implementers should consider the diverse performance Developers or implementers should consider the diverse performance
and conditions of networks on which the Bundle Protocol (and and conditions of networks on which the Bundle Protocol (and
skipping to change at page 34, line 37 skipping to change at page 33, line 28
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
| 11 | Block Integrity Block | This document | | 11 | Block Integrity Block | This document |
| 12 | Block Confidentiality Block | This document | | 12 | Block Confidentiality Block | This document |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
Table 2 Table 2
The Bundle Block Types namespace notes whether a block type is meant
for use in BP version 6, BP version 7, or both. The two block types
defined in this specification are meant for use with BP version 7.
11.2. Security Context Identifiers 11.2. Security Context Identifiers
BPSec has a Security Context Identifier field for which IANA is BPSec has a Security Context Identifier field for which IANA is
requested to create and maintain a new registry named "BPSec Security requested to create and maintain a new registry named "BPSec Security
Context Identifiers". Initial values for this registry are given Context Identifiers". Initial values for this registry are given
below. below.
The registration policy for this registry is: Specification Required. The registration policy for this registry is: Specification Required.
The value range is: unsigned 16-bit integer. The value range is: unsigned 16-bit integer.
skipping to change at page 35, line 21 skipping to change at page 34, line 11
+-------+-------------+---------------+ +-------+-------------+---------------+
Table 3 Table 3
12. References 12. References
12.1. Normative References 12.1. Normative References
[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-14 (work in progress), Version 7", draft-ietf-dtn-bpbis-18 (work in progress),
August 2019. January 2020.
[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>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
skipping to change at page 36, line 27 skipping to change at page 35, line 17
The following participants contributed technical material, use cases, The following participants contributed technical material, use cases,
and useful thoughts on the overall approach to this security and useful thoughts on the overall approach to this security
specification: Scott Burleigh of the Jet Propulsion Laboratory, Amy specification: Scott Burleigh of the Jet Propulsion Laboratory, Amy
Alford and Angela Hennessy of the Laboratory for Telecommunications Alford and Angela Hennessy of the Laboratory for Telecommunications
Sciences, and Angela Dalton and Cherita Corbett of the Johns Hopkins Sciences, and Angela Dalton and Cherita Corbett of the Johns Hopkins
University Applied Physics Laboratory. University Applied Physics Laboratory.
Authors' Addresses Authors' Addresses
Edward J. Birrane, III Edward J. Birrane, III
The Johns Hopkins University Applied Physics Laboratory The Johns Hopkins University Applied
Physics Laboratory
11100 Johns Hopkins Rd. 11100 Johns Hopkins Rd.
Laurel, MD 20723 Laurel, MD 20723
US US
Phone: +1 443 778 7423 Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu Email: Edward.Birrane@jhuapl.edu
Kenneth McKeever Kenneth McKeever
The Johns Hopkins University Applied Physics Laboratory The Johns Hopkins University Applied
Physics Laboratory
11100 Johns Hopkins Rd. 11100 Johns Hopkins Rd.
Laurel, MD 20723 Laurel, MD 20723
US US
Phone: +1 443 778 2237 Phone: +1 443 778 2237
Email: Ken.McKeever@jhuapl.edu Email: Ken.McKeever@jhuapl.edu
 End of changes. 32 change blocks. 
136 lines changed or deleted 101 lines changed or added

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