draft-ietf-dtn-bpsec-12.txt   draft-ietf-dtn-bpsec-13.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: March 21, 2020 September 18, 2019 Expires: May 7, 2020 November 4, 2019
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-12 draft-ietf-dtn-bpsec-13
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 March 21, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11
3.4. Target Identification . . . . . . . . . . . . . . . . . . 11 3.4. Target Identification . . . . . . . . . . . . . . . . . . 11
3.5. Block Representation . . . . . . . . . . . . . . . . . . 12 3.5. Block Representation . . . . . . . . . . . . . . . . . . 12
3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12
3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15
3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16
3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17
3.10. Parameter and Result Identification . . . . . . . . . . . 19 3.10. Parameter and Result Identification . . . . . . . . . . . 18
3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 19 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 19
3.11.1. Example 1: Constructing a Bundle with Security . . . 19 3.11.1. Example 1: Constructing a Bundle with Security . . . 19
3.11.2. Example 2: Adding More Security At A New Node . . . 20 3.11.2. Example 2: Adding More Security At A New Node . . . 20
4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22
5. Security Processing . . . . . . . . . . . . . . . . . . . . . 23 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22
5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23
5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23
5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24
5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 25 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 25
6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 25 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Policy Considerations . . . . . . . . . . . . . . . 25 7. Security Policy Considerations . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8.1. Attacker Capabilities and Objectives . . . . . . . . . . 27 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 27
8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 28 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 28
8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 28 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 28
8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29
8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30
8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 30 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 30
9. Security Context Considerations . . . . . . . . . . . . . . . 31 9. Security Context Considerations . . . . . . . . . . . . . . . 31
9.1. Identification and Configuration . . . . . . . . . . . . 31 9.1. Identification and Configuration . . . . . . . . . . . . 31
9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 32 9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 31
10. Defining Other Security Blocks . . . . . . . . . . . . . . . 33 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 34 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 34
11.2. Security Context Identifiers . . . . . . . . . . . . . . 34 11.2. Security Context Identifiers . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . 35 12.1. Normative References . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . 35 12.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
skipping to change at page 3, line 45 skipping to change at page 3, line 45
authority). authority).
An end-to-end security service is needed that operates in all of the An end-to-end security service is needed that operates in all of the
environments where the BP operates. environments where the BP operates.
1.1. Supported Security Services 1.1. Supported Security Services
BPSec provides end-to-end integrity and confidentiality services for BPSec provides end-to-end integrity and confidentiality services for
BP bundles, as defined in this section. BP bundles, as defined in this section.
Integrity services ensure that changes to target data within a Integrity services ensure that changes to target data within a bundle
bundle, if any, can be discovered. Data changes may be caused by can be discovered. Data changes may be caused by processing errors,
processing errors, environmental conditions, or intentional environmental conditions, or intentional manipulation. In the
manipulation. In the context of BPSec, integrity services apply to context of BPSec, integrity services apply to plain-text in the
plain-text in the bundle. bundle.
Confidentiality services ensure that target data is unintelligible to Confidentiality services ensure that target data is unintelligible to
nodes in the DTN, except for authorized nodes possessing special nodes in the DTN, except for authorized nodes possessing special
information. This generally means producing cipher-text from plain- information. This generally means producing cipher-text from plain-
text and generating authentication information for that cipher-text. text and generating authentication information for that cipher-text.
Confidentiality, in this context, applies to the contents of target Confidentiality, in this context, applies to the contents of target
data and does not extend to hiding the fact that confidentiality data and does not extend to hiding the fact that confidentiality
exists in the bundle. exists in the bundle.
NOTE: Hop-by-hop authentication is NOT a supported security service NOTE: Hop-by-hop authentication is NOT a supported security service
skipping to change at page 6, line 25 skipping to change at page 6, line 25
"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 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 BPA receiving the bundle. The bundle destination acts as the the Bundle Protocol Agent (BPA) receiving the bundle. The bundle
security destination for every security target in every security destination acts as the security destination for every security
block in every bundle it receives. target in every security block in every bundle it receives.
o Bundle Source - the node which originates a bundle. Also, the o Bundle Source - the node which originates a bundle. Also, the
Node ID of the BPA originating the bundle. Node ID of the BPA originating the bundle.
o Cipher Suite - a set of one or more algorithms providing integrity o Cipher Suite - a set of one or more algorithms providing integrity
and confidentiality services. Cipher suites may define necessary and confidentiality services. Cipher suites may define necessary
parameters but do not provide values for those parameters. parameters but do not provide values for those parameters.
o Forwarder - any node that transmits a bundle in the DTN. Also, o Forwarder - any node that transmits a bundle in the DTN. Also,
the Node ID of the Bundle Protocol Agent (BPA) that sent the the Node ID of the BPA that sent the bundle on its most recent
bundle on its most recent hop. hop.
o Intermediate Receiver, Waypoint, or Next Hop - any node that o Intermediate Receiver, Waypoint, or Next Hop - any node that
receives a bundle from a Forwarder that is not the Destination. receives a bundle from a Forwarder that is not the Bundle
Also, the Node ID of the BPA at any such node. Destination. Also, the Node ID of the BPA at any such node.
o Path - the ordered sequence of nodes through which a bundle passes o Path - the ordered sequence of nodes through which a bundle passes
on its way from Source to Destination. The path is not on its way from Source to Destination. The path is not
necessarily known in advance by the bundle or any BPAs in the DTN. necessarily known in advance by the bundle or any BPAs in the DTN.
o Security 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.
skipping to change at page 7, line 22 skipping to change at page 7, line 22
service can only be applied to a security target once in a bundle. service can only be applied to a security target once in a bundle.
A security operation is implemented by a security block. A security operation is implemented by a security block.
o Security Service - the security features supported by this o Security Service - the security features supported by this
specification: either integrity or confidentiality. specification: either integrity or confidentiality.
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
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 application security requirements. This section
section identifies those desirable properties that guide design identifies those desirable properties that guide design decisions for
decisions for this specification and are necessary for understanding this specification and are necessary for understanding the format and
the format and behavior of the BPSec protocol. behavior of the BPSec protocol.
2.1. Block-Level Granularity 2.1. Block-Level Granularity
Security services within this specification must allow different Security services within this specification must allow different
blocks within a bundle to have different security services applied to blocks within a bundle to have different security services applied to
them. them.
Blocks within a bundle represent different types of information. The Blocks within a bundle represent different types of information. The
primary block contains identification and routing information. The primary block contains identification and routing information. The
payload block carries application data. Extension blocks carry a payload block carries application data. Extension blocks carry a
skipping to change at page 10, line 5 skipping to change at page 10, line 5
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. 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
adding a security block to a bundle would cause some other security adding a security block to a bundle would cause some other security
block to no longer represent a unique security operation then the new block to no longer represent a unique security operation then the new
block MUST NOT be added. It is important to note that any cipher- block MUST NOT be added. It is important to note that any cipher-
text integrity mechanism supplied by the BCB is considered part of text integrity mechanism supplied by the BCB is considered part of
the confidentiality service and, therefore, unique from the plain- the confidentiality service and, therefore, unique from the plain-
text integrity service provided by the BIB. text integrity service provided by the BIB.
If multiple security blocks representing the same security operation If multiple security blocks representing the same security operation
were allowed in a bundle at the same time, there would exist were allowed in a bundle at the same time, there would exist
ambiguity regarding block processing order and the property of ambiguity regarding block processing order and the property of
deterministic processing blocks would be lost. deterministic processing of blocks would be lost.
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
skipping to change at page 11, line 20 skipping to change at page 11, line 20
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 context parameters and key information for the o The security context parameters for the security operations are
security operations are identical. 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 by the same node. Meaning the set of operations are being added by the same 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
already present in the bundle. already present in the bundle.
skipping to change at page 15, line 47 skipping to change at page 15, line 47
reference a security block defined in this specification (e.g., a reference a security block defined in this specification (e.g., a
BIB or a BCB). BIB or a BCB).
o The Security Context Id MUST utilize an end-to-end authentication o The Security Context Id MUST utilize an end-to-end authentication
cipher or an end-to-end error detection cipher. cipher or an end-to-end error detection cipher.
o An EID-reference to the security source MAY be present. If this o 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.10. security context information described in Section 3.10.
Notes: Notes:
o It is RECOMMENDED that cipher suite designers carefully consider o It is RECOMMENDED that designers carefully consider the effect of
the effect of setting flags that either discard the block or setting flags that either discard the block or delete the bundle
delete the bundle in the event that this block cannot be in the event that this block cannot be processed.
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
cipher suite. security context.
o For some cipher suites, (e.g., those using asymmetric keying to o For some security contexts, (e.g., those using asymmetric keying
produce signatures or those using symmetric keying with a group to produce signatures or those using symmetric keying with a group
key), the security information MAY be checked at any hop on the key), the security information MAY be checked at any hop on the
way to the destination that has access to the required keying way to the destination that has access to the required keying
information, in accordance with Section 3.9. information, in accordance with Section 3.9.
o The use of a generally available key is RECOMMENDED if custodial
transfer is employed and all nodes SHOULD verify the bundle before
accepting custody.
3.8. Block Confidentiality Block 3.8. Block Confidentiality Block
A BCB is a bundle extension block with the following characteristics. A BCB is a bundle extension block with the following characteristics.
The Block Type Code value is as specified in Section 11.1. The Block Type Code value is as specified in Section 11.1.
The Block Processing Control flags value can be set to whatever The Block Processing Control flags value can be set to whatever
values are required by local policy, except that this block MUST values are required by local policy, except that this block MUST
have the "replicate in every fragment" flag set if the target of have the "replicate in every fragment" flag set if the target of
the BCB is the Payload Block. Having that BCB in each fragment the BCB is the Payload Block. Having that BCB in each fragment
skipping to change at page 17, line 11 skipping to change at page 17, line 5
Additional information created by a cipher suite (such as Additional information created by a cipher suite (such as
additional authenticated data) can be placed either in a security additional authenticated data) can be placed either in a security
result field or in the generated cipher-text. The determination result field or in the generated cipher-text. The determination
of where to place these data is a function of the cipher suite and of where to place these data is a function of the cipher suite and
security context used. security context used.
An EID-reference to the security source MAY be present. If this 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
the key information described in Section 3.10. security context information described in Section 3.10.
The BCB modifies the contents of its security target(s). When a BCB The BCB modifies the contents of its security target(s). When a BCB
is applied, the security target body data are encrypted "in-place". is applied, the security target body data are encrypted "in-place".
Following encryption, the security target Block Type Specific Data Following encryption, the security target Block Type Specific Data
field contains cipher-text, not plain-text. Other block fields field contains cipher-text, not plain-text. Other block fields
remain unmodified, with the exception of the Block Data Length field, remain unmodified, with the exception of the Block Data Length field,
which MUST be updated to reflect the new length of the Block Type which MUST be updated to reflect the new length of the Block Type
Specific Data field. Specific Data field.
Notes: Notes:
o It is RECOMMENDED that cipher suite designers carefully consider o It is RECOMMENDED that designers carefully consider the effect of
the effect of setting flags that either discard the block or setting flags that either discard the block or delete the bundle
delete the bundle in the event that this block cannot be in the event that this block cannot be processed.
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.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
skipping to change at page 18, line 49 skipping to change at page 18, line 41
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 possibly 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 security context that generates such signatures as additional
results SHOULD be used instead. security results SHOULD be used instead.
3.10. Parameter and Result Identification 3.10. Parameter and Result Identification
Each security context MUST define its own context parameters and Each security context MUST define its own context parameters and
security results. Each defined parameter and result is represented results. Each defined parameter and result is represented as the
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
need to be unique amongst all security contexts. need to be unique amongst all security contexts.
3.11. 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
skipping to change at page 19, line 32 skipping to change at page 19, line 24
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.11.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, the second
extension blocks, and the payload. The resultant bundle is extension block, and the payload. The bundle source also wishes to
illustrated in Figure 3 and the security actions are described below. provide confidentiality for the first extension block. The resultant
bundle is illustrated in Figure 3 and the security actions are
described below.
Block in Bundle ID Block in Bundle ID
+======================================+====+ +======================================+====+
| Primary Block | B1 | | Primary Block | B1 |
+--------------------------------------+----+ +--------------------------------------+----+
| BIB | B2 | | BIB | B2 |
| OP(integrity, targets=B1, B5, B6) | | | OP(integrity, targets=B1, B5, B6) | |
+--------------------------------------+----+ +--------------------------------------+----+
| BCB | B3 | | BCB | B3 |
| OP(confidentiality, target=B4) | | | OP(confidentiality, target=B4) | |
skipping to change at page 20, line 39 skipping to change at page 20, line 17
This is accomplished by a single BIB (B2) with multiple targets. This is accomplished by a single BIB (B2) with multiple targets.
A single BIB is used in this case because all three targets share A single BIB is used in this case because all three targets share
a security source, security context, and security context a security source, security context, and security context
parameters. Had this not been the case, multiple BIBs could have parameters. Had this not been the case, 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 populates 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 security context is
to form the BCB. A plain-text integrity signature may also exist used to form the BCB. A plain-text integrity signature may also
as a security result in the BCB if one is provided by the selected exist as a security result in the BCB if one is provided by the
confidentiality cipher suite. selected confidentiality security context.
3.11.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 second
extension block and the bundle payload. The waypoint security policy extension block and the bundle payload. The waypoint security policy
is to allow existing BIBs for these blocks to persist, as they may be is to allow existing BIBs for these blocks to persist, as they may be
required as part of the security policy at the bundle destination. required as part of the security policy at the bundle destination.
The resultant bundle is illustrated in Figure 4 and the security The resultant bundle is illustrated in Figure 4 and the security
actions are described below. Note that block IDs provided here are actions are described below. Note that block IDs provided here are
ordered solely for the purpose of this example and not meant to ordered solely for the purpose of this example and not meant to
impose an ordering for block creation. The ordering of blocks added impose an ordering for block creation. The ordering of blocks added
to a bundle MUST always be in compliance with [I-D.ietf-dtn-bpbis]. to a bundle MUST always be in compliance with [I-D.ietf-dtn-bpbis].
skipping to change at page 21, line 22 skipping to change at page 21, line 16
+======================================+====+ +======================================+====+
| Primary Block | B1 | | Primary Block | B1 |
+--------------------------------------+----+ +--------------------------------------+----+
| BIB | B2 | | BIB | B2 |
| OP(integrity, targets=B1) | | | OP(integrity, targets=B1) | |
+--------------------------------------+----+ +--------------------------------------+----+
| BIB (encrypted) | B7 | | BIB (encrypted) | B7 |
| OP(integrity, targets=B5, B6) | | | OP(integrity, targets=B5, B6) | |
+--------------------------------------+----+ +--------------------------------------+----+
| BCB | B8 | | BCB | B8 |
| OP(confidentiality, target=B4,B6,B7) | | | OP(confidentiality, target=B5,B6,B7) | |
+--------------------------------------+----+ +--------------------------------------+----+
| BCB | B3 | | BCB | B3 |
| OP(confidentiality, target=B4) | | | OP(confidentiality, target=B4) | |
+--------------------------------------+----+ +--------------------------------------+----+
| Extension Block (encrypted) | B4 | | Extension Block (encrypted) | B4 |
+--------------------------------------+----+ +--------------------------------------+----+
| Extension Block (encrypted) | B5 | | Extension Block (encrypted) | B5 |
+--------------------------------------+----+ +--------------------------------------+----+
| Payload Block (encrypted) | B6 | | Payload Block (encrypted) | B6 |
+--------------------------------------+----+ +--------------------------------------+----+
skipping to change at page 24, line 12 skipping to change at page 24, line 7
(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.
When a BCB is decrypted, the recovered plain-text MUST replace the When a BCB is decrypted, the recovered plain-text MUST replace the
cipher-text in the security target Block Type Specific Data Fields. cipher-text in the security target Block Type Specific Data Fields.
If the Block Data Length field was modified at the time of encryption If the Block Data Length field was modified at the time of encryption
it MUST be updated to reflect the decrypted block length. it MUST be updated to reflect the decrypted block length.
If a BCB contains multiple security operations, each operation If a BCB contains multiple security operations, each operation
processed by the node MUST be be treated as if the security operation processed by the node MUST be be treated as if the security operation
has been represented by a single BCB with a single security has been represented by a single BCB with a single security operation
operation. for the purposes of report generation and policy processing.
5.1.2. Receiving BIBs 5.1.2. Receiving BIBs
If a received bundle contains a BIB, the receiving node MUST If a received bundle contains a BIB, the receiving node MUST
determine whether it is the security destination for any of the determine whether it is the security destination for any of the
security operations in the BIB. If so, the node MUST process those security operations in the BIB. If so, the node MUST process those
operations and remove any operation-specific information from the BIB operations and remove any operation-specific information from the BIB
prior to delivering data to an application at the node or forwarding prior to delivering data to an application at the node or forwarding
the bundle. If processing a security operation fails, the target the bundle. If processing a security operation fails, the target
SHALL be processed according to the security policy. A bundle status SHALL be processed according to the security policy. A bundle status
skipping to change at page 25, line 9 skipping to change at page 25, line 4
anyway to prevent forwarding corrupt data. If the verification anyway to prevent forwarding corrupt data. If the verification
fails, the node SHALL process the security target in accordance to fails, the node SHALL process the security target in accordance to
local security policy. It is RECOMMENDED that if a payload integrity local security policy. It is RECOMMENDED that if a payload integrity
check fails at a waypoint that it is processed in the same way as if check fails at a waypoint that it is processed in the same way as if
the check fails at the bundle destination. If the check passes, the the check fails at the bundle destination. If the check passes, the
node MUST NOT remove the security operation from the BIB prior to node MUST NOT remove the security operation from the BIB prior to
forwarding. forwarding.
If a BIB contains multiple security operations, each operation If a BIB contains multiple security operations, each operation
processed by the node MUST be be treated as if the security operation processed by the node MUST be be treated as if the security operation
has been represented by a single BIB with a single security has been represented by a single BIB with a single security operation
operation. for the purposes of report generation and policy processing.
5.2. Bundle Fragmentation and Reassembly 5.2. Bundle Fragmentation and Reassembly
If it is necessary for a node to fragment a bundle payload, and If it is necessary for a node to fragment a bundle payload, and
security services have been applied to that bundle, the fragmentation security services have been applied to that bundle, the fragmentation
rules described in [I-D.ietf-dtn-bpbis] MUST be followed. As defined rules described in [I-D.ietf-dtn-bpbis] MUST be followed. As defined
there and summarized here for completeness, only the payload block there and summarized here for completeness, only the payload block
can be fragmented; security blocks, like all extension blocks, can can be fragmented; security blocks, like all extension blocks, can
never be fragmented. never be fragmented.
skipping to change at page 31, line 26 skipping to change at page 31, line 18
9. Security Context Considerations 9. Security Context Considerations
9.1. Identification and Configuration 9.1. Identification and Configuration
Security blocks must uniquely define the security context for their Security blocks must uniquely define the security context for their
services. This context MUST be uniquely identifiable and MAY use services. This context MUST be uniquely identifiable and MAY use
parameters for customization. Where policy and configuration parameters for customization. Where policy and configuration
decisions can be captured as parameters, the security context decisions can be captured as parameters, the security context
identifier may identify a cipher suite. In cases where the same identifier may identify a cipher suite. In cases where the same
cipher suites are used with differing predetermined configurations cipher suites are used with differing predetermined configurations
and policies, users can define multiple security contexts. and policies, users can define multiple security contexts that use
the same cipher suite.
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
skipping to change at page 32, line 7 skipping to change at page 31, line 48
| | | predetermined key and predetermined key | | | | predetermined key and predetermined key |
| | | rotation policy. | | | | rotation policy. |
| 3 | Nil | AES-GCM-256 cipher suite with all info | | 3 | Nil | AES-GCM-256 cipher suite with all info |
| | | predetermined. | | | | predetermined. |
+---------+------------+--------------------------------------------+ +---------+------------+--------------------------------------------+
Table 1 Table 1
9.2. Authorship 9.2. Authorship
Cipher suite developers or implementers should consider the diverse Developers or implementers should consider the diverse performance
performance and conditions of networks on which the Bundle Protocol and conditions of networks on which the Bundle Protocol (and
(and therefore BPSec) will operate. Specifically, the delay and therefore BPSec) will operate. Specifically, the delay and capacity
capacity of delay-tolerant networks can vary substantially. Cipher of delay-tolerant networks can vary substantially. Developers should
suite developers should consider these conditions to better describe consider these conditions to better describe the conditions when
the conditions when those suites will operate or exhibit those contexts will operate or exhibit vulnerability, and selection
vulnerability, and selection of these suites for implementation of these contexts for implementation should be made with
should be made with consideration to the reality. There are key consideration for this reality. There are key differences that may
differences that may limit the opportunity to leverage existing limit the opportunity for a security context to leverage existing
cipher suites and technologies that have been developed for use in cipher suites and technologies that have been developed for use in
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
skipping to change at page 34, line 37 skipping to change at page 34, line 31
11.1. Bundle Block Types 11.1. Bundle Block Types
This specification allocates two block types from the existing This specification allocates two block types from the existing
"Bundle Block Types" registry defined in [I-D.ietf-dtn-bpbis]. "Bundle Block Types" registry defined in [I-D.ietf-dtn-bpbis].
Additional Entries for the Bundle Block-Type Codes Registry: Additional Entries for the Bundle Block-Type Codes Registry:
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
| 2 | Block Integrity Block | This document | | 11 | Block Integrity Block | This document |
| 3 | Block Confidentiality Block | This document | | 12 | Block Confidentiality Block | This document |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
Table 2 Table 2
11.2. Security Context Identifiers 11.2. Security Context Identifiers
BPSec has a Security Context Identifier field for which IANA is BPSec has a Security Context Identifier field for which IANA is
requested to create and maintain a new registry named "BPSec Security requested to create and maintain a new registry named "BPSec Security
Context Identifiers". Initial values for this registry are given Context Identifiers". Initial values for this registry are given
below. below.
 End of changes. 34 change blocks. 
75 lines changed or deleted 72 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/