draft-ietf-dtn-bpsec-22.txt   draft-ietf-dtn-bpsec-23.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 Intended status: Standards Track JHU/APL
Expires: September 9, 2020 March 8, 2020 Expires: April 28, 2021 October 25, 2020
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-22 draft-ietf-dtn-bpsec-23
Abstract Abstract
This document defines a security protocol providing data integrity This document defines a security protocol providing data integrity
and confidentiality services for the Bundle Protocol. and confidentiality services for the Bundle Protocol.
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.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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 September 9, 2020. This Internet-Draft will expire on April 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Supported Security Services . . . . . . . . . . . . . . . 3 1.1. Supported Security Services . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . 9 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 9
2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9
2.5. Deterministic Processing . . . . . . . . . . . . . . . . 10 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9
3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 12 3.4. Target Identification . . . . . . . . . . . . . . . . . . 12
3.5. Block Representation . . . . . . . . . . . . . . . . . . 13 3.5. Block Representation . . . . . . . . . . . . . . . . . . 13
3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 13 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 13
3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 16 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 16
3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 17 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 17
3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 18 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 18
3.10. Parameter and Result Identification . . . . . . . . . . . 19 3.10. Parameter and Result Identification . . . . . . . . . . . 19
3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 20 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 20
3.11.1. Example 1: Constructing a Bundle with Security . . . 20 3.11.1. Example 1: Constructing a Bundle with Security . . . 20
3.11.2. Example 2: Adding More Security At A New Node . . . 21 3.11.2. Example 2: Adding More Security At A New Node . . . 21
4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 23 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 23
5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24
5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 24 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 24
5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 24 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 24
5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 25 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 25
5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 26 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 26
6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 26 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Policy Considerations . . . . . . . . . . . . . . . 26 7. Security Policy Considerations . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7.1. Security Reason Codes . . . . . . . . . . . . . . . . . . 28
8.1. Attacker Capabilities and Objectives . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 29 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 30
8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 29 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 31
8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 30 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 31
8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 31 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 32
8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 32 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 33
9. Security Context Considerations . . . . . . . . . . . . . . . 32 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 33
9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 32 9. Security Context Considerations . . . . . . . . . . . . . . . 34
9.2. Identification and Configuration . . . . . . . . . . . . 33 9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 34
9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 34 9.2. Identification and Configuration . . . . . . . . . . . . 35
10. Defining Other Security Blocks . . . . . . . . . . . . . . . 35 9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 36
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 37
11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 37 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.2. Security Context Identifiers . . . . . . . . . . . . . . 37 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 11.2. Bundle Status Report Reason Codes . . . . . . . . . . . 39
12.1. Normative References . . . . . . . . . . . . . . . . . . 37 11.3. Security Context Identifiers . . . . . . . . . . . . . . 40
12.2. Informative References . . . . . . . . . . . . . . . . . 38 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 39 12.1. Normative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 12.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
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 security services between a security Networks (DTNs) to provide security services between a security
source and a security acceptor. When the security source is the source and a security acceptor. When the security source is the
bundle source and when the security acceptor is the bundle bundle source and when the security acceptor is the bundle
destination, the security service provides end-to-end protection. destination, the security service provides end-to-end protection.
skipping to change at page 4, line 24 skipping to change at page 4, line 28
NOTE: Hop-by-hop authentication is NOT a supported security service NOTE: Hop-by-hop authentication is NOT a supported security service
in this specification, for two reasons. in this specification, for two reasons.
1. The term "hop-by-hop" is ambiguous in a BP overlay, as nodes that 1. The term "hop-by-hop" is ambiguous in a BP overlay, as nodes that
are adjacent in the overlay may not be adjacent in physical are adjacent in the overlay may not be adjacent in physical
connectivity. This condition is difficult or impossible to connectivity. This condition is difficult or impossible to
detect and therefore hop-by-hop authentication is difficult or detect and therefore hop-by-hop authentication is difficult or
impossible to enforce. impossible to enforce.
2. Networks in which BPSec may be deployed may have a mixture of 2. Hop-by-hop authentication cannot be deployed in a network if
security-aware and not-security-aware nodes. Hop-by-hop adjacent nodes in the network have incompatible security
authentication cannot be deployed in a network if adjacent nodes capabilities.
in the network have different security capabilities.
1.2. Specification Scope 1.2. Specification Scope
This document defines the security services provided by the BPSec. This document defines the security services provided by the BPSec.
This includes the data specification for representing these services This includes the data specification for representing these services
as BP extension blocks, and the rules for adding, removing, and as BP extension blocks, and the rules for adding, removing, and
processing these blocks at various points during the bundle's processing these blocks at various points during the bundle's
traversal of the DTN. traversal of the DTN.
BPSec applies only to those nodes that implement it, known as
"security-aware" nodes. There might be other nodes in the DTN that
do not implement BPSec. While all nodes in a BP overlay can exchange
bundles, BPSec security operations can only happen at BPSec security-
aware nodes.
BPSec addresses only the security of data traveling over the DTN, not BPSec addresses only the security of data traveling over the DTN, not
the underlying DTN itself. Furthermore, while the BPSec protocol can the underlying DTN itself. Furthermore, while the BPSec protocol can
provide security-at-rest in a store-carry-forward network, it does provide security-at-rest in a store-carry-forward network, it does
not address threats which share computing resources with the DTN and/ not address threats which share computing resources with the DTN and/
or BPSec software implementations. These threats may be malicious or BPSec software implementations. These threats may be malicious
software or compromised libraries which intend to intercept data or software or compromised libraries which intend to intercept data or
recover cryptographic material. Here, it is the responsibility of recover cryptographic material. Here, it is the responsibility of
the BPSec implementer to ensure that any cryptographic material, the BPSec implementer to ensure that any cryptographic material,
including shared secret or private keys, is protected against access including shared secret or private keys, is protected against access
within both memory and storage devices. within both memory and storage devices.
Completely trusted networks are extremely uncommon. Amongst
untrusted networks, different networking conditions and operational
considerations require varying strengths of security mechanism.
Mandating a single security context may result in too much security
for some networks and too little security in others. It is expected
that separate documents define different security contexts for use in
different networks. A set of default security contexts are defined
in ([I-D.ietf-dtn-bpsec-interop-sc]) and provide basic security
services for interoperability testing and for operational use on the
terrestrial Internet.
This specification addresses neither the fitness of externally- This specification addresses neither the fitness of externally-
defined cryptographic methods nor the security of their defined cryptographic methods nor the security of their
implementation. Completely trusted networks are extremely uncommon. implementation.
Amongst untrusted networks, different networking conditions and
operational considerations require varying strengths of security
mechanism. Mandating a cipher suite in this specification may result
in too much security for some networks and too little security in
others. It is expected that separate documents will be standardized
to define security contexts and cipher suites compatible with BPSec,
to include those that should be used to assess interoperability and
those fit for operational use in various network scenarios. An
example security context has been defined
([I-D.ietf-dtn-bpsec-interop-sc]) to support interoperability testing
and illustrate how security contexts should be defined for this
specification.
This specification does not address the implementation of security This specification does not address the implementation of security
policy and does not provide a security policy for the BPSec. Similar policy and does not provide a security policy for the BPSec. Similar
to cipher suites, security policies are based on the nature and to cipher suites, security policies are based on the nature and
capabilities of individual networks and network operational concepts. capabilities of individual networks and network operational concepts.
This specification does provide policy considerations when building a This specification does provide policy considerations when building a
security policy. security policy.
With the exception of the Bundle Protocol, this specification does With the exception of the Bundle Protocol, this specification does
not address how to combine the BPSec security blocks with other not address how to combine the BPSec security blocks with other
skipping to change at page 6, line 18 skipping to change at page 6, line 13
Security Protocol [I-D.birrane-dtn-sbsp] documents introduced the Security Protocol [I-D.birrane-dtn-sbsp] documents introduced the
concepts of using BP extension blocks for security services in a DTN. concepts of using BP extension blocks for security services in a DTN.
The BPSec is a continuation and refinement of these documents. The BPSec is a continuation and refinement of these documents.
1.4. Terminology 1.4. Terminology
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.
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 acceptor 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.
skipping to change at page 7, line 14 skipping to change at page 7, line 8
o Security Acceptor - a bundle node that processes and dispositions o Security Acceptor - a bundle node that processes and dispositions
one or more security blocks in a bundle. Also, the Node ID of one or more security blocks in a bundle. Also, the Node ID of
that node. 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 Operation - the application of a security service to a o Security Operation - the application of a given security service
security target, notated as OP(security service, security target). to a security target, notated as OP(security service, security
For example, OP(confidentiality, payload). Every security target). For example, OP(confidentiality, payload). Every
operation in a bundle MUST be unique, meaning that a security security operation in a bundle MUST be unique, meaning that a
service can only be applied to a security target once in a bundle. given security service can only be applied to a security target
A security operation is implemented by a security block. once in a bundle. A security operation is implemented by a
security block.
o Security Service - a process that gives some protection to a o Security Service - a process that gives some protection to a
security target. For example, this specification defines security security target. For example, this specification defines security
services for plain text integrity, plain text confidentiality, and services for plain text integrity, plain text confidentiality, and
cipher text integrity. cipher text integrity.
o Security Source - a bundle node that adds a security block to a o Security Source - a bundle node that adds a security block to a
bundle. Also, the Node ID of that node. bundle. Also, the Node ID of that node.
o Security Target - the block within a bundle that receives a o Security Target - the block within a bundle that receives a
skipping to change at page 8, line 26 skipping to change at page 8, line 22
A bundle can have multiple security blocks and these blocks can have A bundle can have multiple security blocks and these blocks can have
different security sources. BPSec implementations MUST NOT assume different security sources. BPSec implementations MUST NOT assume
that all blocks in a bundle have the same security operations applied that all blocks in a bundle have the same security operations applied
to them. to them.
The Bundle Protocol allows extension blocks to be added to a bundle The Bundle Protocol allows extension blocks to be added to a bundle
at any time during its existence in the DTN. When a waypoint adds a at any time during its existence in the DTN. When a waypoint adds a
new extension block to a bundle, that extension block MAY have new extension block to a bundle, that extension block MAY have
security services applied to it by that waypoint. Similarly, a security services applied to it by that waypoint. Similarly, a
waypoint MAY add a security service to an existing extension block, waypoint MAY add a security service to an existing block, consistent
consistent with its security policy. with its security policy.
When a waypoint adds a security service to the bundle, the waypoint When a waypoint adds a security service to the bundle, the waypoint
is the security source for that service. The security block(s) which is the security source for that service. The security block(s) which
represent that service in the bundle may need to record this security represent that service in the bundle may need to record this security
source as the bundle destination might need this information for source as the bundle destination might need this information for
processing. processing.
For example, a bundle source may choose to apply an integrity service For example, a bundle source may choose to apply an integrity service
to its plain text payload. Later a waypoint node, representing a to its plain text payload. Later a waypoint node, representing a
gateway to another portion of the DTN, may receive the bundle and gateway to another portion of the DTN, may receive the bundle and
skipping to change at page 9, line 9 skipping to change at page 9, line 9
to ensure that a bundle be delivered to a security acceptor prior to to ensure that a bundle be delivered to a security acceptor prior to
being delivered to the bundle destination. Generally, if a bundle being delivered to the bundle destination. Generally, if a bundle
reaches a waypoint that has the appropriate configuration and policy reaches a waypoint that has the appropriate configuration and policy
to act as a security acceptor for a security service in the bundle, to act as a security acceptor for a security service in the bundle,
then the waypoint should act as that security acceptor. then the waypoint should act as that security acceptor.
2.3. Mixed Security Policy 2.3. Mixed Security Policy
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
process security blocks. Therefore, security blocks must have their
processing flags set such that the block will be treated
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 acceptor 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
skipping to change at page 10, line 27 skipping to change at page 10, line 18
3. Security Blocks 3. Security Blocks
3.1. Block Definitions 3.1. Block Definitions
This specification defines two types of security block: the Block This specification defines two types of security block: the Block
Integrity Block (BIB) and the Block Confidentiality Block (BCB). Integrity Block (BIB) and the Block Confidentiality Block (BCB).
The BIB is used to ensure the integrity of its plain text security The BIB is used to ensure the integrity of its plain text security
target(s). The integrity information in the BIB MAY be verified target(s). The integrity information in the BIB MAY be verified
by any node along the bundle path from the BIB security source to by any node along the bundle path from the BIB security source to
the bundle destination. Security-aware waypoints add or remove the bundle destination. Waypoints add or remove BIBs from bundles
BIBs from bundles in accordance with their security policy. BIBs in accordance with their security policy. BIBs are never used for
are never used for integrity protection of the cipher text integrity protection of the cipher text provided by a BCB.
provided by a BCB. Because security policy at BPSec nodes may differ regarding
integrity verification, BIBs do not guarantee hop-by-hop
authentication, as discussed in Section 1.1.
The BCB indicates that the security target(s) have been encrypted The BCB indicates that the security target(s) have been encrypted
at the BCB security source in order to protect their content while at the BCB security source in order to protect their content while
in transit. The BCB is decrypted by security-aware nodes in the in transit. The BCB is decrypted by security acceptor nodes in
network, up to and including the bundle destination, as a matter the network, up to and including the bundle destination, as a
of security policy. BCBs additionally provide integrity matter of security policy. BCBs additionally provide integrity
protection mechanisms for the cipher text they generate. protection mechanisms for the cipher text they generate.
3.2. Uniqueness 3.2. Uniqueness
Security operations in a bundle MUST be unique; the same security Security operations in a bundle MUST be unique; the same security
service MUST NOT be applied to a security target more than once in a service MUST NOT be applied to a security target more than once in a
bundle. Since a security operation is represented as a security bundle. Since a security operation is represented by a security
block, this limits what security blocks may be added to a bundle: if block, this means that multiple security blocks of the same type
adding a security block to a bundle would cause some other security cannot share the same security targets. A new security block MUST
block to no longer represent a unique security operation then the new NOT be added to a bundle if a pre-existing security block of the same
block MUST NOT be added. type is already defined for the security target of the new security
block.
The uniqueness requirement imposed by this specification implies that
the security source for some security target is providing the initial
service for that target. This is the case when the security source
is also the source of the target. This can also occur when the
security source is adding the service to a pre-existing target for
the first time. If more complex security combinations are required,
this specification allows for the definition of custom security
contexts (Section 9) and other security blocks (Section 10).
A security operation may be removed from a bundle as part of
processing a security block and, once removed, the same security
operation may be re-applied by adding a new security block into the
bundle. In this case, conflicting security blocks never co-exist in
the bundle at the same time.
It is important to note that any cipher text integrity mechanism
supplied by the BCB is considered part of the confidentiality service
and, therefore, unique from the plain text integrity service provided
by the BIB.
If multiple security blocks representing the same security operation This uniqueness requirement ensures that there is no ambiguity
were allowed in a bundle at the same time, there would exist related to the order in which security blocks are processed or how
ambiguity regarding block processing order and the property of security policy can be specified to require certain security services
deterministic processing of blocks would be lost. be present in a bundle.
Using the notation OP(service, target), several examples illustrate Using the notation OP(service, target), several examples illustrate
this uniqueness requirement. this uniqueness requirement.
o Signing the payload twice: The two operations OP(integrity, o Signing the payload twice: The two operations OP(integrity,
payload) and OP(integrity, payload) are redundant and MUST NOT payload) and OP(integrity, payload) are redundant and MUST NOT
both be present in the same bundle at the same time. both be present in the same bundle at the same time.
o Signing different blocks: The two operations OP(integrity, o Signing different blocks: The two operations OP(integrity,
payload) and OP(integrity, extension_block_1) are not redundant payload) and OP(integrity, extension_block_1) are not redundant
and both may be present in the same bundle at the same time. and both may be present in the same bundle at the same time.
Similarly, the two operations OP(integrity, extension_block_1) and Similarly, the two operations OP(integrity, extension_block_1) and
OP(integrity,extension_block_2) are also not redundant and may OP(integrity,extension_block_2) are also not redundant and may
both be present in the bundle at the same time. both be present in the bundle at the same time.
o Different Services on same block: The two operations OP(integrity, o Different Services on same block: The two operations OP(integrity,
payload) and OP(confidentiality, payload) are not inherently payload) and OP(confidentiality, payload) are not inherently
redundant and may both be present in the bundle at the same time, redundant and may both be present in the bundle at the same time,
pursuant to other processing rules in this specification. pursuant to other processing rules in this specification.
NOTES:
A security block may be removed from a bundle as part of security
processing at a waypoint node with a new security block being
added to the bundle by that node. In this case, conflicting
security blocks never co-exist in the bundle at the same time and
the uniqueness requirement is not violated.
A cipher text integrity mechanism (such as associated
authenticated data) calculated by a cipher suite and transported
in a BCB is considered part of the confidentiality service and,
therefore, unique from the plain text integrity service provided
by a BIB.
The security blocks defined in this specification (BIB and BCB)
are designed with the intention that the BPA adding these blocks
is the authoritative source of the security service. If a BPA
adds a BIB on a security target, then the BIB is expected to be
the authoritative source of integrity for that security target.
If a BPA adds a BCB to a security target, then the BCB is expected
to be the authoritative source of confidentiality for that
security target. More complex scenarios, such as having multiple
nodes in a network sign the same security target, can be
accommodated using the definition of custom security contexts
(Section 9) and/or the definition of other security blocks
(Section 10).
3.3. Target Multiplicity 3.3. Target Multiplicity
A single security block MAY represent multiple security operations as A single security block MAY represent multiple security operations as
a way of reducing the overall number of security blocks present in a a way of reducing the overall number of security blocks present in a
bundle. In these circumstances, reducing the number of security bundle. In these circumstances, reducing the number of security
blocks in the bundle reduces the amount of redundant information in blocks in the bundle reduces the amount of redundant information in
the bundle. the bundle.
A set of security operations can be represented by a single security A set of security operations can be represented by a single security
block when all of the following conditions are true. block when all of the following conditions are true.
skipping to change at page 14, line 10 skipping to change at page 14, line 10
this array. The order of elements in this list has no semantic this array. The order of elements in this list has no semantic
meaning outside of the context of this block. Within the meaning outside of the context of this block. Within the
block, the ordering of targets must match the ordering of block, the ordering of targets must match the ordering of
results associated with these targets. results associated with these targets.
Security Context Id: Security Context Id:
This field identifies the security context used to implement This field identifies the security context used to implement
the security service represented by this block and applied to the security service represented by this block and applied to
each security target. This field SHALL be represented by a each security target. This field SHALL be represented by a
CBOR unsigned integer. The values for this Id should come from CBOR unsigned integer. The values for this Id should come from
the registry defined in Section 11.2 the registry defined in Section 11.3
Security Context Flags: Security Context Flags:
This field identifies which optional fields are present in the This field identifies which optional fields are present in the
security block. This field SHALL be represented as a CBOR security block. This field SHALL be represented as a CBOR
unsigned integer whose contents shall be interpreted as a bit unsigned integer whose contents shall be interpreted as a bit
field. Each bit in this bit field indicates the presence (bit field. Each bit in this bit field indicates the presence (bit
set to 1) or absence (bit set to 0) of optional data in the set to 1) or absence (bit set to 0) of optional data in the
security block. The association of bits to security block data security block. The association of bits to security block data
is defined as follows. is defined as follows.
skipping to change at page 14, line 47 skipping to change at page 14, line 47
block in the bundle. If the security source field is not block in the bundle. If the security source field is not
present then the source MUST be inferred from other present then the source MUST be inferred from other
information, such as the bundle source, previous hop, or other information, such as the bundle source, previous hop, or other
values defined by security policy. This field SHALL be values defined by security policy. This field SHALL be
represented by a CBOR array in accordance with represented by a CBOR array in accordance with
[I-D.ietf-dtn-bpbis] rules for representing Endpoint [I-D.ietf-dtn-bpbis] rules for representing Endpoint
Identifiers (EIDs). Identifiers (EIDs).
Security Context Parameters (Optional): Security Context Parameters (Optional):
This field captures one or more security context parameters This field captures one or more security context parameters
that should be provided to security-aware nodes when processing that should be used when processing the security service
the security service described by this security block. This described by this security block. This field SHALL be
field SHALL be represented by a CBOR array. Each entry in this represented by a CBOR array. Each entry in this array is a
array is a single security context parameter. A single single security context parameter. A single parameter SHALL
parameter SHALL also be represented as a CBOR array comprising also be represented as a CBOR array comprising a 2-tuple of the
a 2-tuple of the id and value of the parameter, as follows. id and value of the parameter, as follows.
* Parameter Id. This field identifies which parameter is * Parameter Id. This field identifies which parameter is
being specified. This field SHALL be represented as a CBOR being specified. This field SHALL be represented as a CBOR
unsigned integer. Parameter Ids are selected as described unsigned integer. Parameter Ids are selected as described
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.
skipping to change at page 16, line 49 skipping to change at page 16, line 49
an error detection mechanism. an error detection mechanism.
The EID of the security source MAY be present. If this field is The EID of the security source MAY be present. If this field is
not present, then the security source of the block SHOULD be not present, then the security source of the block SHOULD 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 parameters described in Section 3.10. security context parameters described in Section 3.10.
Notes: Notes:
o It is recommended that designers carefully consider the effect of o Designers SHOULD carefully consider the effect of setting flags
setting flags that either discard the block or delete the bundle that either discard the block or delete the bundle in the event
in the event that this block cannot be processed. 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 mechanisms for the same target define a multi-result
security context. security context. Such a context could generate multiple security
results for the same security target using different integrity-
protection mechanisms or different configurations for the same
integrity-protection mechanism.
o A BIB is used to verify the plain text integrity of its security
target. However, a single BIB MAY include security results for
blocks other than its security target when doing so establishes a
needed relationship between the BIB security target and other
blocks in the bundle (such as the primary block).
o Security information MAY be checked at any hop on the way to the o Security information MAY be checked at any hop on the way to the
bundle destination that has access to the required keying bundle destination that has access to the required keying
information, in accordance with Section 3.9. 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.
skipping to change at page 17, line 37 skipping to change at page 17, line 46
it can't be processed" flag set. Removing a BCB from a bundle it can't be processed" flag set. Removing a BCB from a bundle
without decrypting its security targets removes information from without decrypting its security targets removes information from
the bundle necessary for their later decryption. the bundle necessary for their later decryption.
The block-type-specific-data fields follow the structure of the The block-type-specific-data fields follow the structure of the
ASB. ASB.
A security target listed in the Security Targets field can A security target listed in the Security Targets field can
reference the payload block, a non-security extension block, or a reference the payload block, a non-security extension block, or a
BIB. A BCB MUST NOT include another BCB as a security target. A BIB. A BCB MUST NOT include another BCB as a security target. A
BCB MUST NOT target the primary block. BCB MUST NOT target the primary block. A BCB MUST NOT target a
BIB block unless it shares a security target with that BIB block.
The Security Context MUST utilize a confidentiality cipher that Any Security Context used by a BCB MUST utilize a confidentiality
provides authenticated encryption with associated data (AEAD). cipher that provides authenticated encryption with associated data
(AEAD).
Additional information created by a cipher suite (such as an Additional information created by a cipher suite (such as an
authentication tag) can be placed either in a security result authentication tag) can be placed either in a security result
field or in the generated cipher text. The determination of where field or in the generated cipher text. The determination of where
to place this information is a function of the cipher suite and to place this information is a function of the cipher suite and
security context used. security context used.
The EID of the security source MAY be present. If this field is The EID of the security source MAY be present. If this field is
not present, then the security source of the block SHOULD be not present, then the security source of the block SHOULD be
inferred according to security policy and MAY default to the inferred according to security policy and MAY default to the
skipping to change at page 18, line 29 skipping to change at page 18, line 41
for the encrypting node. for the encrypting node.
3.9. Block Interactions 3.9. Block Interactions
The security block types defined in this specification are designed The security block types defined in this specification are designed
to be as independent as possible. However, there are some cases to be as independent as possible. However, there are some cases
where security blocks may share a security target creating processing where security blocks may share a security target creating processing
dependencies. dependencies.
If a security target of a BCB is also a security target of a BIB, an If a security target of a BCB is also a security target of a BIB, an
undesirable condition occurs where a security aware waypoint would be undesirable condition occurs where a waypoint would be unable to
unable to validate the BIB because one of its security target's validate the BIB because one of its security target's contents have
contents have been encrypted by a BCB. To address this situation the been encrypted by a BCB. To address this situation the following
following processing rules MUST be followed. processing rules MUST be followed.
o When adding a BCB to a bundle, if some (or all) of the security o When adding a BCB to a bundle, if some (or all) of the security
targets of the BCB also match all of the security targets of an targets of the BCB also match all of the security targets of an
existing BIB, then the existing BIB MUST also be encrypted. This existing BIB, then the existing BIB MUST also be encrypted. This
can be accomplished by either adding a new BCB that targets the can be accomplished by either adding a new BCB that targets the
existing BIB, or by adding the BIB to the list of security targets existing BIB, or by adding the BIB to the list of security targets
for the BCB. Deciding which way to represent this situation is a for the BCB. Deciding which way to represent this situation is a
matter of security policy. matter of security policy.
o When adding a BCB to a bundle, if some (or all) of the security o When adding a BCB to a bundle, if some (or all) of the security
skipping to change at page 19, line 31 skipping to change at page 19, line 42
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.
In cases where a security source wishes to calculate both a plain In cases where a security source wishes to calculate both a plain
text integrity mechanism and encrypt a security target, a BCB with a text integrity mechanism and encrypt a security target, a BCB with a
security context that generates such signatures as additional security context that generates an integrity-protection mechanism as
security results MUST be used instead of adding both a BIB and then a one or more additional security results MUST be used instead of
BCB for the security target at the security source. adding both a BIB and then a BCB for the security target at the
security source.
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 23, line 8 skipping to change at page 23, line 12
(B5) and the payload (B6) as well as the newly created BIB holding (B5) and the payload (B6) as well as the newly created BIB holding
their plain text integrity signatures (B7). A single new BCB is their plain text integrity signatures (B7). A single new BCB is
used in this case because all three targets share a security used in this case because all three targets share a security
source, security context, and security context parameters. Had source, security context, and security context parameters. Had
this not been the case, multiple BCBs could have been added this not been the case, multiple BCBs could have been added
instead. instead.
4. Canonical Forms 4. Canonical Forms
Security services require consistency and determinism in how Security services require consistency and determinism in how
information is presented to cipher suites at the security source and information is presented to cipher suites at security sources,
at a receiving node. For example, integrity services require that verifiers, and acceptors. For example, integrity services require
the same target information (e.g., the same bits in the same order) that the same target information (e.g., the same bits in the same
is provided to the cipher suite when generating an original signature order) is provided to the cipher suite when generating an original
and when validating a signature. Canonicalization algorithms are signature and when validating a signature. Canonicalization
used to construct a stable, end-to-end bit representation of a target algorithms transcode the contents of a security target into a
block. canonical form.
Canonical forms are used to generate input to a security context for Canonical forms are used to generate input to a security context for
security processing at a security-aware node. security processing at a BP node. If the values of a security target
are unchanged, then the canonical form of that target will be the
same even if the encoding of those values for wire transmission is
different.
BPSec operates on data fields within bundle blocks (e.g., the block- BPSec operates on data fields within bundle blocks (e.g., the block-
type-specific-data field). In their canonical form, these fields type-specific-data field). In their canonical form, these fields
MUST include their own CBOR encoding and MUST NOT include any other MUST include their own CBOR encoding and MUST NOT include any other
encapsulating CBOR encoding. For example, the canonical form of the encapsulating CBOR encoding. For example, the canonical form of the
block-type-specific-data field is a CBOR byte string existing within block-type-specific-data field is a CBOR byte string existing within
the CBOR array containing the fields of the extension block. The the CBOR array containing the fields of the extension block. The
entire CBOR byte string is considered the canonical block-type- entire CBOR byte string is considered the canonical block-type-
specific-data field. The CBOR array framing is not considered part specific-data field. The CBOR array framing is not considered part
of the field. of the field.
The canonical form of the primary block is specified in The canonical form of the primary block is as specified in
[I-D.ietf-dtn-bpbis]. [I-D.ietf-dtn-bpbis] with the following constraint.
o CBOR values from the primary block MUST be canonicalized using the
rules for Canonical CBOR, as specified in [RFC7049]. Canonical
CBOR generally requires that integers and type lengths are encoded
to be as small as possible, that map values be sorted, and that
indefinite-length items be made into definite-length items.
All non-primary blocks share the same block structure and are All non-primary blocks share the same block structure and are
canonicalized as specified in [I-D.ietf-dtn-bpbis] with the following canonicalized as specified in [I-D.ietf-dtn-bpbis] with the following
exceptions. constraints.
o If the service being applied is a confidentiality service, then o CBOR values from the non-primary block MUST be canonicalized using
the block type code, block number, block processing control flags, the rules for Canonical CBOR, as specified in [RFC7049].
CRC type and CRC field (if present), and the length indication of
the block-type-specific-data field MUST NOT be included in a
canonical form. Confidentiality services are used solely to
convert block data in the block-type-specific-data field from
plain text to cipher text.
o Reserved flags in the block processing control flags field MUST be o Only the block-type-specific-data field may be provided to a
set to 0 in a canonical form as it is not known if those flags cipher suite for encryption as part of a confidentiality security
will change in transit. service. Other fields within a non-primary-block MUST NOT be
encrypted or decrypted and MUST NOT be included in the canonical
form used by the cipher suite for encryption and decryption.
These other fields MAY have an integrity protection mechanism
applied to them by treating them as associated authenticated data.
Cipher suites and security contexts MAY define their own o Reserved and unassigned flags in the block processing control
canonicalization algorithms and require the use of those algorithms flags field MUST be set to 0 in a canonical form as it is not
over the ones provided in this specification. In the event of known if those flags will change in transit.
conflicting canonicalization algorithms, those algorithms take
precedence over this specification. Security contexts MAY define their own canonicalization algorithms
and require the use of those algorithms over the ones provided in
this specification. In the event of conflicting canonicalization
algorithms, algorithms defined in a security context take precedence
over this specification when constructing canonical forms for that
security context.
5. Security Processing 5. Security Processing
This section describes the security aspects of bundle processing. This section describes the security aspects of bundle processing.
5.1. Bundles Received from Other Nodes 5.1. Bundles Received from Other Nodes
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 BP 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 acceptor for any of the security determine whether it is the security acceptor for any of the security
operations in the BCB. If so, the node MUST process those operations operations in the BCB. If so, the node MUST process those operations
and remove any operation-specific information from the BCB prior to and remove any operation-specific information from the BCB prior to
skipping to change at page 24, line 35 skipping to change at page 25, line 5
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 node If the security policy of a node specifies that a node should have
should have applied confidentiality to a specific security target and applied confidentiality to a specific security target and no such BCB
no such BCB is present in the bundle, then the node MUST process this is present in the bundle, then the node MUST process this security
security target in accordance with the security policy. It is target in accordance with the security policy. It is RECOMMENDED
recommended that the node remove the security target from the bundle. that the node remove the security target from the bundle because the
If the removed security target is the payload block, the bundle MUST confidentiality (and possibly the integrity) of the security target
be discarded. cannot be guaranteed. If the removed security target is the payload
block, the bundle MUST be discarded.
If an encrypted payload block cannot be decrypted (i.e., the cipher If an encrypted payload block cannot be decrypted (i.e., the cipher
text cannot be authenticated), then the bundle MUST be discarded and text cannot be authenticated), then the bundle MUST be discarded and
processed no further. If an encrypted security target other than the processed no further. If an encrypted security target other than the
payload block cannot be decrypted then the associated security target payload block cannot be decrypted then the associated security target
and all security blocks associated with that target MUST be discarded and all security blocks associated with that target MUST be discarded
and processed no further. In both cases, requested status reports and processed no further. In both cases, requested status reports
(see [I-D.ietf-dtn-bpbis]) MAY be generated to reflect bundle or (see [I-D.ietf-dtn-bpbis]) MAY be generated to reflect bundle or
block deletion. block deletion.
skipping to change at page 25, line 39 skipping to change at page 26, line 8
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
processing the BCB. processing the BCB.
If the security policy of a security-aware node specifies that a node If the security policy of a node specifies that a node should have
should have applied integrity to a specific security target and no applied integrity to a specific security target and no such BIB is
such BIB is present in the bundle, then the node MUST process this present in the bundle, then the node MUST process this security
security target in accordance with the security policy. It is target in accordance with the security policy. It is RECOMMENDED
RECOMMENDED that the node remove the security target from the bundle that the node remove the security target from the bundle if the
if the security target is not the payload or primary block. If the security target is not the payload or primary block. If the security
security target is the payload or primary block, the bundle MAY be target is the payload or primary block, the bundle MAY be discarded.
discarded. This action can occur at any node that has the ability to This action can occur at any node that has the ability to verify an
verify an integrity signature, not just the bundle destination. integrity signature, not just the bundle destination.
If a receiving node is not the security acceptor 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.
skipping to change at page 27, line 25 skipping to change at page 27, line 43
of the bundle, the destination of the bundle, or some other of the bundle, the destination of the bundle, or some other
information related to the bundle. information related to the bundle.
o If a waypoint has been configured to add a security operation to a o If a waypoint has been configured to add a security operation to a
bundle, and the received bundle already has the security operation bundle, and the received bundle already has the security operation
applied, then the receiver must understand what to do. The applied, then the receiver must understand what to do. The
receiver may discard the bundle, discard the security target and receiver may discard the bundle, discard the security target and
associated BPSec blocks, replace the security operation, or some associated BPSec blocks, replace the security operation, or some
other action. other action.
o It is recommended that security operations be considered for every o It is RECOMMENDED that security operations be applied to every
block in a bundle and that the default behavior of a bundle agent block in a bundle and that the default behavior of a bundle agent
is to use the security services defined in this specification. is to use the security services defined in this specification.
Designers should only deviate from the use of security operations Designers should only deviate from the use of security operations
when the deviation can be justified - such as when doing so causes when the deviation can be justified - such as when doing so causes
downstream errors when processing blocks whose contents must be downstream errors when processing blocks whose contents must be
inspected or changed at one or more hops along the path. inspected or changed at one or more hops along the path.
o It is recommended that BCBs be allowed to alter the size of o BCB security contexts can alter the size of extension blocks and
extension blocks and the payload block. However, care must be the payload block. Security policy SHOULD consider how changes to
taken to ensure that changing the size of the payload block while the size of a block could negatively effect bundle processing
the bundle is in transit do not negatively affect bundle (e.g., calculating storage needs and scheduling transmission
processing (e.g., calculating storage needs, scheduling times).
transmission times).
o Adding a BIB to a security target that has already been encrypted o Adding a BIB to a security target that has already been encrypted
by a BCB is not allowed. If this condition is likely to be by a BCB is not allowed. If this condition is likely to be
encountered, there are (at least) three possible policies that encountered, there are (at least) three possible policies that
could handle this situation. could handle this situation.
1. At the time of encryption, a security context can be selected 1. At the time of encryption, a security context can be selected
which computes a plain text integrity signature and included which computes a plain text integrity-protection mechanism
as a security context result field. that is included as a security context result field.
2. The encrypted block may be replicated as a new block with a 2. The encrypted block may be replicated as a new block with a
new block number and given integrity protection. new block number and given integrity protection.
3. An encapsulation scheme may be applied to encapsulate the 3. An encapsulation scheme may be applied to encapsulate the
security target (or the entire bundle) such that the security target (or the entire bundle) such that the
encapsulating structure is, itself, no longer the security encapsulating structure is, itself, no longer the security
target of a BCB and may therefore be the security target of a target of a BCB and may therefore be the security target of a
BIB. BIB.
o It is recommended that security policy address whether cipher o Security policy SHOULD address whether cipher suites whose cipher
suites whose cipher text is larger than the initial plain text are text is larger than the initial plain text are permitted and, if
permitted and, if so, for what types of blocks. Changing the size so, for what types of blocks. Changing the size of a block may
of a block may cause processing difficulties for networks that cause processing difficulties for networks that calculate block
calculate block offsets into bundles or predict transmission times offsets into bundles or predict transmission times or storage
or storage availability as a function of bundle size. In other availability as a function of bundle size. In other cases,
cases, changing the size of a payload as part of encryption has no changing the size of a payload as part of encryption has no
significant impact. significant impact.
7.1. Security Reason Codes
Bundle protocol agents (BPAs) must process blocks and bundles in
accordance with both BP policy and BPSec policy. The decision to
receive, forward, deliver, or delete a bundle may be communicated to
the report-to address of the bundle, in the form of a status report,
as a method of tracking the progress of the bundle through the
network. The status report for a bundle may be augmented with a
"reason code" explaining why the particular action was taken on the
bundle.
This section describes a set of reason codes associated with the
security processing of a bundle. Security reason codes are assigned
in accordance with Section 11.2.
Missing Security Operation:
This reason code indicates that a bundle was missing one or
more required security operations. This reason code is
typically used by a security verifier or security acceptor.
Unknown Security Operation:
This reason code indicates that one or more security operations
present in a bundle cannot be understood by the security
verifier or security acceptor for the operation. For example,
this reason code may be used if a security block references an
unknown security context identifier or security context
parameter. This reason code should not be used for security
operations for which the node is not a security verifier or
security acceptor; there is no requirement that all nodes in a
network understand all security contexts, security context
parameters, and security services for every bundle in a
network.
Unexpected Security Operation:
This reason code indicates that a receiving node is neither a
security verifier nor a security acceptor for at least one
security operation in a bundle. This reason code should not be
seen as an error condition; not every node is a security
verifier or security acceptor for every security operation in
every bundle. In certain networks, this reason code may be
useful in identifying misconfigurations of security policy.
Failed Security Operation:
This reason code indicates that one or more security operations
in a bundle failed to process as expected for reasons other
than misconfiguration. This may occur when a security-source
is unable to add a security block to a bundle. This may occur
if the target of a security operation fails to verify using the
defined security context at a security verifier. This may also
occur if a security operation fails to be processed without
error at a security acceptor.
Conflicting Security Operations:
This reason code indicates that two or more security operations
in a bundle are not conformant with the BPSec specification and
that security processing was unable to proceed because of a
BPSec protocol violation.
8. Security Considerations 8. Security Considerations
Given the nature of DTN applications, it is expected that bundles may Given the nature of DTN applications, it is expected that bundles may
traverse a variety of environments and devices which each pose unique traverse a variety of environments and devices which each pose unique
security risks and requirements on the implementation of security security risks and requirements on the implementation of security
within BPSec. For these reasons, it is important to introduce key within BPSec. For these reasons, it is important to introduce key
threat models and describe the roles and responsibilities of the threat models and describe the roles and responsibilities of the
BPSec protocol in protecting the confidentiality and integrity of the BPSec protocol in protecting the confidentiality and integrity of the
data against those threats. This section provides additional data against those threats. This section provides additional
discussion on security threats that BPSec will face and describes how discussion on security threats that BPSec will face and describes how
skipping to change at page 28, line 48 skipping to change at page 30, line 27
portions of the DTN) are completely under the control of an attacker. portions of the DTN) are completely under the control of an attacker.
8.1. Attacker Capabilities and Objectives 8.1. Attacker Capabilities and Objectives
BPSec was designed to protect against MITM threats which may have BPSec was designed to protect against MITM threats which may have
access to a bundle during transit from its source, Alice, to its access to a bundle during transit from its source, Alice, to its
destination, Bob. A MITM node, Mallory, is a non-cooperative node destination, Bob. A MITM node, Mallory, is a non-cooperative node
operating on the DTN between Alice and Bob that has the ability to operating on the DTN between Alice and Bob that has the ability to
receive bundles, examine bundles, modify bundles, forward bundles, receive bundles, examine bundles, modify bundles, forward bundles,
and generate bundles at will in order to compromise the and generate bundles at will in order to compromise the
confidentiality or integrity of data within the DTN. For the confidentiality or integrity of data within the DTN. There are three
purposes of this section, any MITM node is assumed to effectively be classes of MITM nodes which are differentiated based on their access
security-aware even if it does not implement the BPSec protocol. to cryptographic material:
There are three classes of MITM nodes which are differentiated based
on their access to cryptographic material:
o Unprivileged Node: Mallory has not been provisioned within the o Unprivileged Node: Mallory has not been provisioned within the
secure environment and only has access to cryptographic material secure environment and only has access to cryptographic material
which has been publicly-shared. which has been publicly-shared.
o Legitimate Node: Mallory is within the secure environment and o Legitimate Node: Mallory is within the secure environment and
therefore has access to cryptographic material which has been therefore has access to cryptographic material which has been
provisioned to Mallory (i.e., K_M) as well as material which has provisioned to Mallory (i.e., K_M) as well as material which has
been publicly-shared. been publicly-shared.
skipping to change at page 33, line 13 skipping to change at page 34, line 42
inappropriate for use in a well-resourced, well connected node. inappropriate for use in a well-resourced, well connected node.
This does not mean that the use of BPSec in a particular network is This does not mean that the use of BPSec in a particular network is
meant to be used without security contexts for interoperability and meant to be used without security contexts for interoperability and
default behavior. Network designers must identify the minimal set of default behavior. Network designers must identify the minimal set of
security contexts necessary for functions in their network. For security contexts necessary for functions in their network. For
example, a default set of security contexts could be created for use example, a default set of security contexts could be created for use
over the terrestrial Internet and required by any BPSec over the terrestrial Internet and required by any BPSec
implementation communicating over the terrestrial Internet. implementation communicating over the terrestrial Internet.
Implementations of BPSec MUST support the mandated security contexts To ensure interoperability among various implementations, all BPSec
of the networks in which they are applied. If no set of security implementations MUST support at least the current IETF standards-
contexts is mandated for a given network, then the BPSec track mandatory security context(s). As of this writing, that BCP
implementation MUST, at a minimum, implement the security context mandatory security context is specified in
defined in [I-D.ietf-dtn-bpsec-interop-sc]. If a node serves as a [I-D.ietf-dtn-bpsec-interop-sc], but the mandatory security
gateway amongst two or more networks, the BPSec implementation at context(s) might change over time in accordance with usual IETF
that node MUST support the union of security contexts mandated in processes. Such changes are likely to occur in the future if/when
those networks. flaws are discovered in the applicable cryptographic algorithms, for
example.
Additionally, BPsec implementations need to support the security
contexts which are specified and/or used by the BP networks in which
they are deployed.
If a node serves as a gateway amongst two or more networks, the BPSec
implementation at that node needs to support the union of security
contexts mandated in those networks.
BPSec has been designed to allow for a diversity of security contexts BPSec has been designed to allow for a diversity of security contexts
and for new contexts to be defined over time. The use of different and for new contexts to be defined over time. The use of different
security contexts does not change the BPSec protocol itself and the security contexts does not change the BPSec protocol itself and the
definition of new security contexts MUST adhere to the requirements definition of new security contexts MUST adhere to the requirements
of such contexts as presented in this section and generally in this of such contexts as presented in this section and generally in this
specification. specification.
Implementors should monitor the state of security context Implementors should monitor the state of security context
specifications to check for future updates and replacement. specifications to check for future updates and replacement.
9.2. Identification and Configuration 9.2. Identification and Configuration
Security blocks must uniquely define the security context for their Security blocks uniquely identify the security context to be used in
services. This context MUST be uniquely identifiable and MAY use the processing of their security services. The security context for
parameters for customization. Where policy and configuration a security block MUST be uniquely identifiable and MAY use parameters
decisions can be captured as parameters, the security context for customization.
identifier may identify a cipher suite. In cases where the same
cipher suites are used with differing predetermined configurations To reduce the number of security contexts used in a network, security
and policies, users can define multiple security contexts that use context designers should make security contexts customizable through
the same cipher suite. the definition of security context parameters. For example, a single
security context could be associated with a single cipher suite and
security context parameters could be used to configure the use of
this security context with different key lengths and different key
management options without needing to define separate security
contexts for each possible option.
A single security context may be used in the application of more than
one security service. This means that a security context identifier
MAY be used with a BIB, with a BCB, or with any other BPSec-compliant
security block. The definition of a security context MUST identify
which security services may be used with the security context, how
security context parameters are interpreted as a function of the
security operation being supported, and which security results are
produced for each security service.
Network operators must determine the number, type, and configuration Network operators must determine the number, type, and configuration
of security contexts in a system. Networks with rapidly changing of security contexts in a system. Networks with rapidly changing
configurations may define relatively few security contexts with each configurations may define relatively few security contexts with each
context customized with multiple parameters. For networks with more context customized with multiple parameters. For networks with more
stability, or an increased need for confidentiality, a larger number stability, or an increased need for confidentiality, a larger number
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 | Encrypted | AES-GCM-256 cipher suite with provided | | 1 | Encrypted | AES-GCM-256 cipher suite with provided |
| | Key, IV | ephemeral key encrypted with a | | | Key, IV | ephemeral key encrypted with a |
| | | predetermined key encryption key and clear | | | | predetermined key encryption key and clear |
| | | text initialization vector. | | | | text 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.3. Authorship 9.3. 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 37, line 25 skipping to change at page 39, line 30
| TBA | Block Integrity Block | This document | | TBA | Block Integrity Block | This document |
| TBA | Block Confidentiality Block | This document | | TBA | Block Confidentiality Block | This document |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
Table 2 Table 2
The Bundle Block Types namespace notes whether a block type is meant 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 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. defined in this specification are meant for use with BP version 7.
11.2. Security Context Identifiers 11.2. Bundle Status Report Reason Codes
This specification allocates five reason codes from the existing
"Bundle Status Report Reason Codes" registry defined in [RFC6255].
Additional Entries for the Bundle Status Report Reason Codes
Registry:
+---------+-------+-----------------------+-------------------------+
| BP | Value | Description | Reference |
| Version | | | |
+---------+-------+-----------------------+-------------------------+
| 7 | TBD | Missing Security | This document, Section |
| | | Operation | Section 7.1 |
| 7 | TBD | Unknown Security | This document, Section |
| | | Operation | Section 7.1 |
| 7 | TBD | Unexpected Security | This document, Section |
| | | Operation | Section 7.1 |
| 7 | TBD | Failed Security | This document, Section |
| | | Operation | Section 7.1 |
| 7 | TBD | Conflicting Security | This document, Section |
| | | Operation | Section 7.1 |
+---------+-------+-----------------------+-------------------------+
11.3. 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.
BPSec Security Context Identifier Registry BPSec Security Context Identifier Registry
+-------+-------------+---------------+ +-------+-------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------+---------------+ +-------+-------------+---------------+
| < 0 | Reserved | This document |
| 0 | Reserved | This document | | 0 | Reserved | This document |
+-------+-------------+---------------+ +-------+-------------+---------------+
Table 3 Table 3
Negative security context identifiers are reserved for local/site-
specific uses. The use of 0 as a security context identifier is for
non-operational testing purposes only.
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-22 (work in progress), Version 7", draft-ietf-dtn-bpbis-26 (work in progress),
February 2020. July 2020.
[I-D.ietf-dtn-bpsec-interop-sc] [I-D.ietf-dtn-bpsec-interop-sc]
Birrane, E., "BPSec Interoperability Security Contexts", Birrane, E., "BPSec Interoperability Security Contexts",
draft-ietf-dtn-bpsec-interop-sc-01 (work in progress), draft-ietf-dtn-bpsec-interop-sc-01 (work in progress),
February 2020. February 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>.
skipping to change at page 39, line 22 skipping to change at page 42, line 8
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, specification: Scott Burleigh of the Jet Propulsion Laboratory,
Angela Hennessy of the Laboratory for Telecommunications Sciences, Angela Hennessy of the Laboratory for Telecommunications Sciences,
and Amy Alford, Angela Dalton, and Cherita Corbett of the Johns and Amy Alford, Angela Dalton, and Cherita Corbett of the Johns
Hopkins University Applied Physics Laboratory. Hopkins 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. 51 change blocks. 
208 lines changed or deleted 343 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/