draft-ietf-dtn-bpsec-08.txt   draft-ietf-dtn-bpsec-09.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: April 25, 2019 October 22, 2018 Expires: August 25, 2019 February 21, 2019
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-08 draft-ietf-dtn-bpsec-09
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.
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 April 25, 2019. This Internet-Draft will expire on August 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . 7 2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 7
2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8
2.4. User-Selected Cipher Suites . . . . . . . . . . . . . . . 8 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 8
2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9
3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9
3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10
3.4. Target Identification . . . . . . . . . . . . . . . . . . 11 3.4. Target Identification . . . . . . . . . . . . . . . . . . 11
3.5. Block Representation . . . . . . . . . . . . . . . . . . 11 3.5. Block Representation . . . . . . . . . . . . . . . . . . 11
3.6. Security Association Block . . . . . . . . . . . . . . . 12 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12
3.7. Abstract Security Block . . . . . . . . . . . . . . . . . 14 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 14
3.8. Block Integrity Block . . . . . . . . . . . . . . . . . . 17 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 15
3.9. Block Confidentiality Block . . . . . . . . . . . . . . . 18 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17
3.10. Block Interactions . . . . . . . . . . . . . . . . . . . 19 3.10. Parameter and Result Identification . . . . . . . . . . . 18
3.11. SA Parameters and Result Identification . . . . . . . . . 20 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 18
3.12. BSP Block Examples . . . . . . . . . . . . . . . . . . . 21 3.11.1. Example 1: Constructing a Bundle with Security . . . 19
3.12.1. Example 1: Constructing a Bundle with Security . . . 21 3.11.2. Example 2: Adding More Security At A New Node . . . 20
3.12.2. Example 2: Adding More Security At A New Node . . . 22 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 21
4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 24 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22
5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 22
5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 25 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 22
5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 25 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 23
5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 26 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 24
5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 27 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 24
6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 27 7. Security Policy Considerations . . . . . . . . . . . . . . . 24
7. Security Policy Considerations . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 26
8.1. Attacker Capabilities and Objectives . . . . . . . . . . 29 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 27
8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 30 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 27
8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 30 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 28
8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 31 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 29
8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 32 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 29
8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 32 9. Security Context Considerations . . . . . . . . . . . . . . . 30
9. Cipher Suite Authorship Considerations . . . . . . . . . . . 33 9.1. Identification and Configuration . . . . . . . . . . . . 30
10. Defining Other Security Blocks . . . . . . . . . . . . . . . 34 9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 32
11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 35 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 37 12.1. Normative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 12.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34
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 5, line 14 skipping to change at page 5, line 15
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.
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. Different networking conditions and operational implementation. Different networking conditions and operational
considerations require varying strengths of security mechanism such considerations require varying strengths of security mechanism such
that mandating a cipher suite in this specification may result in too that mandating a cipher suite in this specification may result in too
much security for some networks and too little security in others. much security for some networks and too little security in others.
It is expected that separate documents will be standardized to define It is expected that separate documents will be standardized to define
cipher suites compatible with BPSec, to include operational cipher security contexts and cipher suites compatible with BPSec, to include
suites and interoperability cipher suites. those that should be used to assess interoperability and those fit
for operational use in various network scenarios.
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 16 skipping to change at page 6, line 16
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 "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 Source - the node which originates a bundle. The Node ID o Bundle Source - the node which originates a bundle. Also, the
of the BPA originating the bundle. Node ID of the BPA originating the bundle.
o Forwarder - any node that transmits a bundle in the DTN. The Node o Cipher Suite - a set of one or more algorithms providing integrity
ID of the Bundle Protocol Agent (BPA) that sent the bundle on its and confidentiality services. Cipher suites may define necessary
most recent hop. parameters but do not provide values for those parameters.
o Intermediate Receiver, Waypoint, or "Next Hop" - any node that o Forwarder - any node that transmits a bundle in the DTN. Also,
the Node ID of the Bundle Protocol Agent (BPA) that sent the
bundle on its most recent hop.
o Intermediate Receiver, Waypoint, or Next Hop - any node that
receives a bundle from a Forwarder that is not the Destination. receives a bundle from a Forwarder that is not the Destination.
The Node ID of the BPA at any such node. 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 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,
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 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: integrity and confidentiality. specification: either integrity or confidentiality.
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. 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
security-service as part of a security-operation. security-service as part of a security-operation.
2. Design Decisions 2. Design Decisions
The application of security services in a DTN is a complex endeavor The application of security services in a DTN is a complex endeavor
that must consider physical properties of the network, policies at that must consider physical properties of the network, policies at
each node, and various application security requirements. This each node, and various application security requirements. This
section identifies those desirable properties that guide design section identifies those desirable properties that guide design
skipping to change at page 8, line 5 skipping to change at page 8, line 9
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 extension block,
consistent with its security policy. consistent 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. For example, a destination node might interpret policy processing.
as it related to security blocks as a function of the security source
for that block.
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 an insecure portion of the DTN, may receive the bundle and gateway to an insecure portion of the DTN, may receive the bundle and
choose to apply a confidentiality service. In this case, the choose to apply a confidentiality service. In this case, the
integrity security source is the bundle source and the integrity security source is the bundle source and the
confidentiality security source is the waypoint node. confidentiality security source is the waypoint node.
2.3. Mixed Security Policy 2.3. Mixed Security Policy
skipping to change at page 8, line 43 skipping to change at page 8, line 45
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
its path. its path.
Some waypoints could understand security blocks but refuse to process Some waypoints could understand security blocks but refuse to process
them unless they are the bundle destination. them unless they are the bundle destination.
2.4. User-Selected Cipher Suites 2.4. User-Defined Security Contexts
The security services defined in this specification rely on a variety A security context is the union of security algorithms (cipher
of cipher suites providing integrity signatures, cipher-text, and suites), policies associated with the use of those algorithms, and
other information necessary to populate security blocks. Users may configuration values. Different contexts may specify different
select different cipher suites to implement security services. For algorithms, different polices, or different configuration values used
example, some users might prefer a SHA2 hash function for integrity in the implementation of their security services. BPSec must provide
whereas other users might prefer a SHA3 hash function instead. The a mechanism for users to define their own security contexts.
For example, some users might prefer a SHA2 hash function for
integrity whereas other users might prefer a SHA3 hash function. The
security services defined in this specification must provide a security services defined in this specification must provide a
mechanism for identifying what cipher suite has been used to populate mechanism for determining what cipher suite, policy, and
a security block. configuration has been used to populate a security block.
2.5. Deterministic Processing 2.5. Deterministic Processing
Whenever a node determines that it must process more than one Whenever a node determines that it must process more than one
security block in a received bundle (either because the policy at a security block in a received bundle (either because the policy at a
waypoint states that it should process security blocks or because the waypoint states that it should process security blocks or because the
node is the bundle destination) the order in which security blocks node is the bundle destination) the order in which security blocks
are processed must be deterministic. All nodes must impose this same are processed must be deterministic. All nodes must impose this same
deterministic processing order for all security blocks. This deterministic processing order for all security blocks. This
specification provides determinism in the application and evaluation specification provides determinism in the application and evaluation
of security services, even when doing so results in a loss of of security services, even when doing so results in a loss of
flexibility. flexibility.
3. Security Blocks 3. Security Blocks
3.1. Block Definitions 3.1. Block Definitions
This specification defines three types of security block: the This specification defines two types of security block: the Block
Security Association Block (SAB), the Block Integrity Block (BIB) and Integrity Block (BIB) and the Block Confidentiality Block (BCB).
the Block Confidentiality Block (BCB).
The SAB is used to define security associations between two
messaging endpoints. In this sense, they are similar to security
associations used in other security protocols such as IPSec, with
the exception that these associations may be pre-negotiated as a
matter of policy, parameterized as part of their definition, or
otherwise made fit for use in a challenged networking scenario.
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. Security-aware waypoints add or remove
BIBs from bundles in accordance with their security policy. BIBs BIBs from bundles in accordance with their security policy. BIBs
are never used to sign the cipher-text provided by a BCB. are never used to sign the cipher- text provided by a BCB.
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- aware nodes in the
network, up to and including the bundle destination, as a matter network, up to and including the bundle destination, as a matter
of security policy. BCBs additionally provide authentication of security policy. BCBs additionally provide authentication
mechanisms for the cipher-text they generate. 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 as a security
block, this limits what security blocks may be added to a bundle: if block, this limits what security blocks may be added to a bundle: if
skipping to change at page 11, line 9 skipping to change at page 10, line 47
reducing the number of security blocks in the bundle reduces the reducing the number of security blocks in the bundle reduces the
amount of redundant information in the bundle. amount of redundant information in 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.
o The security operations apply the same security service. For o The security operations apply the same security service. For
example, they are all integrity operations or all confidentiality example, they are all integrity operations or all confidentiality
operations. operations.
o The security association parameters and key information for the o The security context parameters and key information for the
security operations are identical. security operations are identical.
o The security source for the security operations is the same. o The security source for the security operations is the same.
Meaning the set of operations are being added/removed by the same Meaning the set of operations are being added/removed by the same
node. node.
o No security operations have the same security target, as that o No security operations have the same security target, as that
would violate the need for security operations to be unique. would violate the need for security operations to be unique.
o None of the security operations conflict with security operations o None of the security operations conflict with security operations
skipping to change at page 12, line 4 skipping to change at page 11, line 46
in [I-D.ietf-dtn-bpbis]. That is, each security block is comprised in [I-D.ietf-dtn-bpbis]. That is, each security block is comprised
of the following elements: of the following elements:
o Block Type Code o Block Type Code
o Block Number o Block Number
o Block Processing Control Flags o Block Processing Control Flags
o CRC Type and CRC Field (if present) o CRC Type and CRC Field (if present)
o Block Data Length o Block Data Length
o Block Type Specific Data Fields o Block Type Specific Data Fields
Security-specific information for a security block is captured in the Security-specific information for a security block is captured in the
"Block Type Specific Data Fields". "Block Type Specific Data Fields".
3.6. Security Association Block 3.6. Abstract Security Block
The SAB defines a security association (SA) between bundle messaging
endpoints. This association captures the set of parameterized cipher
suite information, key information, and other annotative information
necessary to configure security services in the network.
In deployments where data communications are challenged, the SAB
block may be omitted in favor of negotiating SAs using out-of-band
mechanisms.
The Block Type Code of an SAB is as specified in Section 11.1.
The Block number, Block Processing Control Flags, CRC Type and CRC
Field, and Block Data Length may be set in any way that conforms with
security policy and in compliance with [I-D.ietf-dtn-bpbis].
The Block Type Specific Data Fields of the SAB MUST be encoded as a
CBOR array, with each element of the array defining a unique SA.
An individual security association (SA) MUST be encoded as a CBOR
array comprising the following fields, listed in the order in which
they must appear.
Security Association Id:
This field identifies the identifier for the SA. This field
SHALL be represented by a CBOR unsigned integer.
Security Association Flags:
This field identifies which optional fields are present in the
security block. This field SHALL be represented as a CBOR
unsigned integer containing a bit field of 5 bits indicating
the presence or absence of other fields, as follows.
Bit 1 (the most-significant bit, 0x10): EID Scope Flag.
Bit 2 (0x08): Block Type Scope Flag.
Bit 3 (0x04): Cipher Suite Id Present Flag.
Bit 4 (0x02): Security Source Present Flag.
Bit 5 (the least-significant bit, 0x01): Security Association
Parameters Present Flag.
In this field, a value of 1 indicates that the associated
security block field MUST be included in the security block. A
value of 0 indicates that the associated security block field
MUST NOT be in the security block.
EID Scope (Optional Field):
This field identifies the message destinations (as a series of
Endpoints) for which this SA should be applied. If this field
is not present, the SA may be applied to any message endpoints
or may be filtered in some other way in accordance with
security policy. This field SHALL be represented by a CBOR
array with each element containing an EID encoded in accordance
with [I-D.ietf-dtn-bpbis] rules for representing Endpoint
Identifiers (EIDs).
Block Type Scope (Optional Field):
This field identifies the block types for which this SA should
be applied. If this field is not present, the SA may be
applied to any block type or may be filtered in some other way
in accordance with security policy. This field SHALL be
represented by a CBOR array with each element containing a
block type encoded in accordance with [I-D.ietf-dtn-bpbis]
rules for representing block types.
Cipher Suite Id (Optional Field):
This field identifies the cipher suite used by this SA. If
this field is not present, the cipher suite associated with
this SA MUST be known through some alternative mechanisms, such
as local security policy or out-of-band configuration. The
cipher suite Id SHALL be presented by a CBOR unsigned integer.
Security Source (Optional Field):
This field identifies the Endpoint that inserted the security
block in the bundle. If the security source field is not
present then the source MUST be inferred from other
information, such as the bundle source, previous hop, or other
values defined by security policy. This field SHALL be
represented by a CBOR array in accordance with
[I-D.ietf-dtn-bpbis] rules for representing Endpoint
Identifiers (EIDs).
Security Association Parameters (Optional Field):
This field captures one or more security association parameters
that should be provided to security-aware nodes when processing
the security service described by this security block. This
field SHALL be represented by a CBOR array. Each entry in this
array is a single SA parameter. A single SA parameter SHALL
also be represented as a CBOR array comprising a 2-tuple of the
id and value of the parameter, as follows.
* Parameter Id. This field identifies which SA parameter is
being specified. This field SHALL be represented as a CBOR
unsigned integer. Parameter ids are selected as described
in Section 3.11.
* Parameter Value. This field captures the value associated
with this parameter. This field SHALL be represented by the
applicable CBOR representation of the parameter, in
accordance with Section 3.11.
The logical layout of the security association parameters array
is illustrated in Figure 1.
+----------------+----------------+ +----------------+
| Parameter 1 | Parameter 2 | ... | Parameter N |
+------+---------+------+---------+ +------+---------+
| Id | Value | Id | Value | | Id | Value |
+------+---------+------+---------+ +------+---------+
Figure 1: Security Association Parameters
Notes:
o It is RECOMMENDED that security association designers carefully
consider the effect of setting flags that either discard the block
or delete the bundle in the event that this block cannot be
processed.
3.7. Abstract Security Block
The structure of the security-specific portions of a security block The structure of the security-specific portions of a security block
is identical for both the BIB and BCB Block Types. Therefore, this is identical for both the BIB and BCB Block Types. Therefore, this
section defines an Abstract Security Block (ASB) data structure and section defines an Abstract Security Block (ASB) data structure and
discusses the definition, processing, and other constraints for using discusses the definition, processing, and other constraints for using
this structure. An ASB is never directly instantiated within a this structure. An ASB is never directly instantiated within a
bundle, it is only a mechanism for discussing the common aspects of bundle, it is only a mechanism for discussing the common aspects of
BIB and BCB security blocks. BIB and BCB security blocks.
The fields of the ASB SHALL be as follows, listed in the order in The fields of the ASB SHALL be as follows, listed in the order in
skipping to change at page 15, line 15 skipping to change at page 12, line 29
This field identifies the block(s) targeted by the security This field identifies the block(s) targeted by the security
operation(s) represented by this security block. Each target operation(s) represented by this security block. Each target
block is represented by its unique Block Number. This field block is represented by its unique Block Number. This field
SHALL be represented by a CBOR array of data items. Each SHALL be represented by a CBOR array of data items. Each
target within this CBOR array SHALL be represented by a CBOR target within this CBOR array SHALL be represented by a CBOR
unsigned integer. This array MUST have at least 1 entry and unsigned integer. This array MUST have at least 1 entry and
each entry MUST represent the Block Number of a block that each entry MUST represent the Block Number of a block that
exists in the bundle. There MUST NOT be duplicate entries in exists in the bundle. There MUST NOT be duplicate entries in
this array. this array.
Security Association Id: Security Context Id:
This field identifies the cipher suite used to implement the This field identifies the security context used to implement
security service represented by this block and applied to each the security service represented by this block and applied to
security target. This field SHALL be represented by a CBOR each security target. This field SHALL be represented by a
unsigned integer. CBOR unsigned integer.
Security Association 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 containing a bit field of 5 bits indicating unsigned integer containing a bit field of 5 bits indicating
the presence or absence of other security block fields, as the presence or absence of other security block fields, as
follows. follows.
Bit 1 (the most-significant bit, 0x10): reserved. Bit 1 (the most-significant bit, 0x10): reserved.
Bit 2 (0x08): reserved. Bit 2 (0x08): reserved.
Bit 3 (0x04): reserved. Bit 3 (0x04): reserved.
Bit 4 (0x02): Security Source Present Flag. Bit 4 (0x02): Security Source Present Flag.
Bit 5 (the least-significant bit, 0x01): reserved. Bit 5 (the least-significant bit, 0x01): Security Context
Parameters Present Flag.
In this field, a value of 1 indicates that the associated In this field, a value of 1 indicates that the associated
security block field MUST be included in the security block. A security block field MUST be included in the security block. A
value of 0 indicates that the associated security block field value of 0 indicates that the associated security block field
MUST NOT be in the security block. MUST NOT be in the security block.
Security Source (Optional Field): Security Source (Optional):
This field identifies the Endpoint that inserted the security This field identifies the Endpoint that inserted the security
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):
This field captures one or more security context parameters
that should be provided to security-aware nodes when processing
the security service described by this security block. This
field SHALL be represented by a CBOR array. Each entry in this
array is a single security context parameter. A single
parameter SHALL also be represented as a CBOR array comprising
a 2-tuple of the id and value of the parameter, as follows.
* Parameter Id. This field identifies which parameter is
being specified. This field SHALL be represented as a CBOR
unsigned integer. Parameter Ids are selected as described
in Section 3.10.
* Parameter Value. This field captures the value associated
with this parameter. This field SHALL be represented by the
applicable CBOR representation of the parameter, in
accordance with Section 3.10.
The logical layout of the parameters array is illustrated in
Figure 1.
+----------------+----------------+ +----------------+
| Parameter 1 | Parameter 2 | ... | Parameter N |
+------+---------+------+---------+ +------+---------+
| Id | Value | Id | Value | | Id | Value |
+------+---------+------+---------+ +------+---------+
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
array corresponds to the first entry in the Security Targets array corresponds to the first entry in the Security Targets
field of the security block, and so on. There MUST be one field of the security block, and so on. There MUST be one
skipping to change at page 16, line 28 skipping to change at page 14, line 24
The set of security results for a target is also represented as The set of security results for a target is also represented as
a CBOR array of individual results. An individual result is a CBOR array of individual results. An individual result is
represented as a 2-tuple of a result id and a result value, represented as a 2-tuple of a result id and a result value,
defined as follows. defined as follows.
* Result Id. This field identifies which security result is * Result Id. This field identifies which security result is
being specified. Some security results capture the primary being specified. Some security results capture the primary
output of a cipher suite. Other security results contain output of a cipher suite. Other security results contain
additional annotative information from cipher suite additional annotative information from cipher suite
processing. This field SHALL be represented as a CBOR processing. This field SHALL be represented as a CBOR
unsigned integer. Security result ids will be as specified unsigned integer. Security result Ids will be as specified
in Section 3.11. in Section 3.10.
* 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.11. 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 | | Target 1 | | Target N |
+------------+----+------------+ +------------------------------+ +------------+----+------------+ +------------------------------+
| Result 1 | | Result M | ... | Result 1 | | Result K | | Result 1 | | Result M | ... | Result 1 | | Result K |
+----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+
| Id | Value | | Id | Value | | Id | Value | | Id | Value | | Id | Value | | Id | Value | | Id | Value | | Id | Value |
+----+-------+ +----+-------+ +----+-------+ +----+-------+ +----+-------+ +----+-------+ +----+-------+ +----+-------+
Figure 2: Security Results Figure 2: Security Results
3.8. 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 Association Id MUST refer to a known SA that supports o The Security Context Id MUST utilize an end-to-end authentication
an end-to-end authentication-cipher suite or as an end-to-end cipher or an end-to-end error detection cipher.
error-detection-cipher suite.
o An EID-reference to the security source MAY be present. If this o An EID-reference to the security source MAY be present. If this
field is not present, then the security source of the block SHOULD field is not present, then the security source of the block SHOULD
be inferred according to security policy and MAY default to the be 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
key information described in Section 3.11. key information described in Section 3.10.
Notes: Notes:
o It is RECOMMENDED that SA designers carefully consider the effect o It is RECOMMENDED that cipher suite designers carefully consider
of setting flags that either discard the block or delete the the effect of setting flags that either discard the block or
bundle in the event that this block cannot be processed. delete the bundle 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
SA. cipher suite.
o For some SAs, (e.g., those using asymmetric keying to produce o For some cipher suites, (e.g., those using asymmetric keying to
signatures or those using symmetric keying with a group key), the produce signatures or those using symmetric keying with a group
security information MAY be checked at any hop on the way to the key), the security information MAY be checked at any hop on the
destination that has access to the required keying information, in way to the destination that has access to the required keying
accordance with Section 3.10. information, in accordance with Section 3.9.
o The use of a generally available key is RECOMMENDED if custodial o The use of a generally available key is RECOMMENDED if custodial
transfer is employed and all nodes SHOULD verify the bundle before transfer is employed and all nodes SHOULD verify the bundle before
accepting custody. accepting custody.
3.9. 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
the BCB is the Payload Block. Having that BCB in each fragment the BCB is the Payload Block. Having that BCB in each fragment
indicates to a receiving node that the payload portion of each indicates to a receiving node that the payload portion of each
fragment represents cipher-text. fragment represents cipher-text.
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.
The Security Association Id MUST refer to a known SA that supports The Security Context Id MUST utilize a confidentiality cipher that
a confidentiality cipher suite that supports authenticated provides authenticated encryption with associated data (AEAD).
encryption with associated data (AEAD).
Additional information created by the SA (such as additional Additional information created by a cipher suite (such as
authenticated data) can be placed either in a security result additional authenticated data) can be placed either in a security
field or in the generated cipher-text. The determination of where result field or in the generated cipher-text. The determination
to place these data is a function of the cipher suite used. of where to place these data is a function of the cipher suite
used.
An EID-reference to the security source MAY be present. If this An EID-reference to the security source MAY be present. If this
field is not present, then the security source of the block SHOULD field is not present, then the security source of the block SHOULD
be inferred according to security policy and MAY default to the be 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
key information described in Section 3.11. the key 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.
Notes: Notes:
o It is RECOMMENDED that SA designers carefully consider the effect o It is RECOMMENDED that cipher suite designers carefully consider
of setting flags that either discard the block or delete the the effect of setting flags that either discard the block or
bundle in the event that this block cannot be processed. delete the bundle in the event that this block cannot be
processed.
o The BCB block processing control flags can be set independently o The BCB block processing control flags can be set independently
from the processing control flags of the security target(s). The from the processing control flags of the security target(s). The
setting of such flags SHOULD be an implementation/policy decision setting of such flags SHOULD be an implementation/policy decision
for the encrypting node. for the encrypting node.
3.10. 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 security aware waypoint would be
unable to validate the BIB because one of its security target's unable to validate the BIB because one of its security target's
contents have been encrypted by a BCB. To address this situation the contents have been encrypted by a BCB. To address this situation the
skipping to change at page 20, line 14 skipping to change at page 17, line 51
o A BIB integrity value MUST NOT be evaluated if the BIB is the o A BIB integrity value MUST NOT be evaluated if the BIB is the
security target of an existing BCB. In this case, the BIB data is security target of an existing BCB. In this case, the BIB data is
encrypted. encrypted.
o A BIB integrity value MUST NOT be evaluated if the security target o A BIB integrity value MUST NOT be evaluated if the security target
of the BIB is also the security target of a BCB. In such a case, of the BIB is also the security target of a BCB. In such a case,
the security target data contains cipher-text as it has been the security target data contains cipher-text as it has been
encrypted. encrypted.
o As mentioned in Section 3.8, a BIB MUST NOT have a BCB as its o As mentioned in Section 3.7, a BIB MUST NOT have a BCB as its
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 NOTE: Since any cipher suite used with a BCB MUST be an AEAD cipher
suite, it is inefficient and possibly insecure for a single security suite, it is inefficient and possible insecure for a single security
source to add both a BIB and a BCB for the same security target. In source to add both a BIB and a BCB for the same security target. In
cases where a security source wishes to calculate both a plain-text cases where a security source wishes to calculate both a plain-text
integrity mechanism and encrypt a security target, a BCB with a integrity mechanism and encrypt a security target, a BCB with a
cipher suite that generates such signatures as additional security cipher suite that generates such signatures as additional security
results SHOULD be used instead. results SHOULD be used instead.
3.11. SA Parameters and Result Identification 3.10. Parameter and Result Identification
SA parameters and security results each represent multiple distinct Security context parameters and results each represent multiple
pieces of information in a security block. Each piece of information distinct pieces of information in a security block. Each piece of
is assigned an identifier and a CBOR encoding. Identifiers MUST be information is assigned an identifier and a CBOR encoding.
unique for a given SA but do not need to be unique across all SAs. Identifiers MUST be unique for a given cipher suite but do not need
Therefore, parameter ids and security result ids are specified in the to be unique across all cipher suites. Therefore, parameter Ids and
context of an SA definition. result Ids are specified in the context of a cipher suite definition.
Individual BPSec SAs SHOULD use existing registries of identifiers Individual BPSec security context identifiers SHOULD use existing
and CBOR encodings, such as those defined in [RFC8152], whenever registries of identifiers and CBOR encodings, such as those defined
possible. SAs SHOULD define their own identifiers and CBOR encodings in [RFC8152], whenever possible. Contexts SHOULD define their own
when necessary. identifiers and CBOR encodings when necessary.
A SA can include multiple instances of the same identifier for a Parameters and results are represented using CBOR, and any
parameter or result in the SAB. Parameters and results are identification of a new parameter or result must include how the
represented using CBOR, and any identification of a new parameter or value will be represented using the CBOR specification. Ids
result must include how the value will be represented using the CBOR themselves are always represented as a CBOR unsigned integer.
specification. Ids themselves are always represented as a CBOR
unsigned integer.
3.12. BSP Block Examples 3.11. BSP Block Examples
This section provides two examples of BPSec blocks applied to a This section provides two examples of BPSec blocks applied to a
bundle. In the first example, a single node adds several security bundle. In the first example, a single node adds several security
operations to a bundle. In the second example, a waypoint node operations to a bundle. In the second example, a waypoint node
received the bundle created in the first example and adds additional received the bundle created in the first example and adds additional
security operations. In both examples, the first column represents security operations. In both examples, the first column represents
blocks within a bundle and the second column represents the Block blocks within a bundle and the second column represents the Block
Number for the block, using the terminology B1...Bn for the purpose Number for the block, using the terminology B1...Bn for the purpose
of illustration. of illustration.
3.12.1. Example 1: Constructing a Bundle with Security 3.11.1. Example 1: Constructing a Bundle with Security
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, one of the the plain-text associated with the primary block, one of the
extension blocks, and the payload. The resultant bundle is extension blocks, and the payload. The resultant bundle is
illustrated in Figure 3 and the security actions are described below. illustrated in Figure 3 and the security actions are described below.
Block in Bundle ID Block in Bundle ID
+======================================+====+ +======================================+====+
skipping to change at page 21, line 51 skipping to change at page 19, line 40
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 and policy has them share the same cipher suite, a security source, security context, and security context
key, and cipher suite parameters. Had this not been the case, parameters. Had this not been the case, multiple BIBs could have
multiple BIBs could have been added instead. been added instead.
o Confidentiality for the first extension block (B4). This is o Confidentiality for the first extension block (B4). This is
accomplished by a BCB (B3). Once applied, the contents of accomplished by a BCB (B3). Once applied, the contents of
extension block B4 are encrypted. The BCB MUST hold an extension block B4 are encrypted. The BCB MUST hold an
authentication signature for the cipher-text either in the cipher- authentication signature for the cipher-text either in the cipher-
text that now populated the first extension block or as a security text that now populated the first extension block or as a security
result in the BCB itself, depending on which cipher suite is used result in the BCB itself, depending on which cipher suite is used
to form the BCB. A plain-text integrity signature may also exist to form the BCB. A plain-text integrity signature may also exist
as a security result in the BCB if one is provided by the selected as a security result in the BCB if one is provided by the selected
confidentiality cipher suite. confidentiality cipher suite.
3.12.2. Example 2: Adding More Security At A New Node 3.11.2. Example 2: Adding More Security At A New Node
Consider that the bundle as it is illustrated in Figure 3 is now Consider that the bundle as it is illustrated in Figure 3 is now
received by a waypoint node that wishes to encrypt the first received by a waypoint node that wishes to encrypt the first
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
skipping to change at page 23, line 46 skipping to change at page 21, line 11
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
associated with B5 and B6 are moved out of BIB B2 and into BIB B7. associated with B5 and B6 are moved out of BIB B2 and into BIB B7.
o Now that there is no longer confusion of which plain-text o Now that there is no longer confusion of which plain-text
integrity signatures must be encrypted, a BCB is added to the integrity signatures must be encrypted, a BCB is added to the
bundle with the security targets being the second extension block bundle with the security targets being the second extension block
(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 and policy has them share the same cipher suite, key, and source, security context, and security context parameters. Had
cipher suite parameters. Had this not been the case, multiple this not been the case, multiple BCBs could have been added
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 the security source and
at a receiving node. For example, integrity services require that at a receiving node. For example, integrity services require that
the same target information (e.g., the same bits in the same order) the same target information (e.g., the same bits in the same order)
is provided to the cipher suite when generating an original signature is provided to the cipher suite when generating an original signature
and when generating a comparison signature. Canonicalization and when generating a comparison signature. Canonicalization
algorithms are used to construct a stable, end-to-end bit algorithms are used to construct a stable, end-to-end bit
skipping to change at page 24, line 41 skipping to change at page 21, line 51
Fields from plain-text to cipher-text. Fields from plain-text to cipher-text.
o Reserved flags MUST NOT be included in any canonicalization as it o Reserved flags MUST NOT be included in any canonicalization as it
is not known if those flags will change in transit. is not known if those flags will change in transit.
These canonicalization algorithms assume that Endpoint IDs do not These canonicalization algorithms assume that Endpoint IDs do not
change from the time at which a security source adds a security block change from the time at which a security source adds a security block
to a bundle and the time at which a node processes that security to a bundle and the time at which a node processes that security
block. block.
Cipher suites used by SAs MAY define their own canonicalization Cipher suites MAY define their own canonicalization algorithms and
algorithms and require the use of those algorithms over the ones require the use of those algorithms over the ones provided in this
provided in this specification. In the event of conflicting specification. In the event of conflicting canonicalization
canonicalization algorithms, cipher suite algorithms take precedence algorithms, cipher suite algorithms take precedence over this
over this specification. specification.
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 security-aware node. The processing order is as follows.
skipping to change at page 33, line 5 skipping to change at page 30, line 14
BPSec relies on cipher suite capabilities to prevent replay or forged BPSec relies on cipher suite capabilities to prevent replay or forged
message attacks. A BCB used with appropriate cryptographic message attacks. A BCB used with appropriate cryptographic
mechanisms (e.g., a counter-based cipher mode) may provide replay mechanisms (e.g., a counter-based cipher mode) may provide replay
protection under certain circumstances. Alternatively, application protection under certain circumstances. Alternatively, application
data itself may be augmented to include mechanisms to assert data data itself may be augmented to include mechanisms to assert data
uniqueness and then protected with a BIB, a BCB, or both along with uniqueness and then protected with a BIB, a BCB, or both along with
other block data. In such a case, the receiving node would be able other block data. In such a case, the receiving node would be able
to validate the uniqueness of the data. to validate the uniqueness of the data.
9. Cipher Suite Authorship Considerations 9. Security Context Considerations
9.1. Identification and Configuration
Security blocks must uniquely define the security context for their
services. This context MUST be uniquely identifiable and MAY use
parameters for customization. Where policy and configuration
decisions can be captured as parameters, the security context
identifier may identify a cipher suite. In cases where the same
cipher suites are used with differing predetermined configurations
and policies, users can define multiple security contexts.
Network operators must determine the number, type, and configuration
of security contexts in a system. Networks with rapidly changing
configurations may define relatively few security contexts with each
context customized with multiple parameters. For networks with more
stability, or an increased need for confidentiality, a larger number
of contexts can be defined with each context supporting few, if any,
parameters.
Security Context Examples
+---------+------------+--------------------------------------------+
| Context | Parameters | Definition |
| Id | | |
+---------+------------+--------------------------------------------+
| 1 | Key, IV | AES-GCM-256 cipher suite with provided |
| | | ephemeral key and initialization vector. |
| 2 | IV | AES-GCM-256 cipher suite with |
| | | predetermined key and predetermined key |
| | | rotation policy. |
| 3 | Nil | AES-GCM-256 cipher suite with all info |
| | | predetermined. |
+---------+------------+--------------------------------------------+
Table 1
9.2. Authorship
Cipher suite developers or implementers should consider the diverse Cipher suite developers or implementers should consider the diverse
performance and conditions of networks on which the Bundle Protocol performance and conditions of networks on which the Bundle Protocol
(and therefore BPSec) will operate. Specifically, the delay and (and therefore BPSec) will operate. Specifically, the delay and
capacity of delay-tolerant networks can vary substantially. Cipher capacity of delay-tolerant networks can vary substantially. Cipher
suite developers should consider these conditions to better describe suite developers should consider these conditions to better describe
the conditions when those suites will operate or exhibit the conditions when those suites will operate or exhibit
vulnerability, and selection of these suites for implementation vulnerability, and selection of these suites for implementation
should be made with consideration to the reality. There are key should be made with consideration to the reality. There are key
differences that may limit the opportunity to leverage existing differences that may limit the opportunity to leverage existing
skipping to change at page 33, line 27 skipping to change at page 31, line 27
traditional, more reliable networks: traditional, more reliable networks:
o Data Lifetime: Depending on the application environment, bundles o Data Lifetime: Depending on the application environment, bundles
may persist on the network for extended periods of time, perhaps may persist on the network for extended periods of time, perhaps
even years. Cryptographic algorithms should be selected to ensure even years. Cryptographic algorithms should be selected to ensure
protection of data against attacks for a length of time reasonable protection of data against attacks for a length of time reasonable
for the application. for the application.
o One-Way Traffic: Depending on the application environment, it is o One-Way Traffic: Depending on the application environment, it is
possible that only a one-way connection may exist between two possible that only a one-way connection may exist between two
endpoints, or if a two-way connection does exist, the round-trip endpoints, or if a two-way connection does exist, the round- trip
time may be extremely large. This may limit the utility of time may be extremely large. This may limit the utility of
session key generation mechanisms, such as Diffie-Hellman, as a session key generation mechanisms, such as Diffie-Hellman, as a
two-way handshake may not be feasible or reliable. two-way handshake may not be feasible or reliable.
o Opportunistic Access: Depending on the application environment, a o Opportunistic Access: Depending on the application environment, a
given endpoint may not be guaranteed to be accessible within a given endpoint may not be guaranteed to be accessible within a
certain amount of time. This may make asymmetric cryptographic certain amount of time. This may make asymmetric cryptographic
architectures which rely on a key distribution center or other architectures which rely on a key distribution center or other
trust center impractical under certain conditions. trust center impractical under certain conditions.
When developing new cipher suites for use with BPSec, the following When developing new security contexts for use with BPSec, the
information SHOULD be considered for inclusion in these following information SHOULD be considered for inclusion in these
specifications. specifications.
o Cipher Suite Parameters. Cipher suites MUST define their o Security Context Parameters. Security contexts MUST define their
parameter ids, the data types of those parameters, and their CBOR parameter Ids, the data types of those parameters, and their CBOR
encoding. encoding.
o Security Results. Cipher suites MUST define their security result o Security Results. Security contexts MUST define their security
ids, the data types of those results, and their CBOR encoding. result Ids, the data types of those results, and their CBOR
encoding.
o New Canonicalizations. Cipher suites may define new o New Canonicalizations. Security contexts may define new
canonicalization algorithms as necessary. canonicalization algorithms as necessary.
o Cipher-Text Size. Cipher suites MUST state whether they generate o Cipher-Text Size. Security contexts MUST state whether their
cipher-text (to include any included authentication information) associated cipher suites generate cipher-text (to include any
that is of a different size than the input plain-text. authentication information) that is of a different size than the
input plain-text.
If a cipher suite does not wish to alter the size of the plain- If a security context does not wish to alter the size of the
text, it should consider the following. plain-text, it should consider defining the following policy.
* Place overflow bytes, authentication signatures, and any * Place overflow bytes, authentication signatures, and any
additional authenticated data in security result fields rather additional authenticated data in security result fields rather
than in the cipher-text itself. than in the cipher-text itself.
* Pad the cipher-text in cases where the cipher-text is smaller * Pad the cipher-text in cases where the cipher-text is smaller
than the plain-text. than the plain-text.
o If a BCB cannot alter the size of the security target then
differences in the size of the cipher-text and plain-text MUST be
handled in the following way. If the cipher-text is shorter in
length than the plain-text, padding MUST be used in accordance
with the cipher suite policy. If the cipher-text is larger than
the plain-text, overflow bytes MUST be placed in overflow
parameters in the Security Result field. Any additional
authentication information can be treated either as overflow
cipher-text or represented separately in the BCB in a security
result field, in accordance with cipher suite documentation and
security policy.
10. Defining Other Security Blocks 10. Defining Other Security Blocks
Other security blocks (OSBs) may be defined and used in addition to Other security blocks (OSBs) may be defined and used in addition to
the security blocks identified in this specification. Both the usage the security blocks identified in this specification. Both the usage
of BIB, BCB, and any future OSBs can co-exist within a bundle and can of BIB, BCB, and any future OSBs can co-exist within a bundle and can
be considered in conformance with BPSec if each of the following be considered in conformance with BPSec if each of the following
requirements are met by any future identified security blocks. requirements are met by any future identified security blocks.
o Other security blocks (OSBs) MUST NOT reuse any enumerations o Other security blocks (OSBs) MUST NOT reuse any enumerations
identified in this specification, to include the block type codes identified in this specification, to include the block type codes
skipping to change at page 35, line 36 skipping to change at page 33, line 24
and configuration associated with blocks SHOULD be included in any and configuration associated with blocks SHOULD be included in any
OSB definition. OSB definition.
NOTE: The burden of showing compliance with processing rules is NOTE: The burden of showing compliance with processing rules is
placed upon the standards defining new security blocks and the placed upon the standards defining new security blocks and the
identification of such blocks shall not, alone, require maintenance identification of such blocks shall not, alone, require maintenance
of this specification. of this specification.
11. IANA Considerations 11. IANA Considerations
A registry of cipher suite identifiers will be required. A registry of security context identifiers will be required.
11.1. Bundle Block Types 11.1. Bundle Block Types
This specification allocates three block types from the existing This specification allocates two block types from the existing
"Bundle Block Types" registry defined in [RFC6255]. "Bundle Block Types" registry defined in [RFC6255].
Additional Entries for the Bundle Block-Type Codes Registry: Additional Entries for the Bundle Block-Type Codes Registry:
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
| TBD | Security Association Block | This document |
| TBD | Block Integrity Block | This document | | TBD | Block Integrity Block | This document |
| TBD | Block Confidentiality Block | This document | | TBD | Block Confidentiality Block | This document |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
Table 1 Table 2
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-11 (work in progress), Version 7", draft-ietf-dtn-bpbis-11 (work in progress),
May 2018. May 2018.
 End of changes. 69 change blocks. 
300 lines changed or deleted 237 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/