draft-ietf-dtn-bpsec-05.txt   draft-ietf-dtn-bpsec-06.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: January 2, 2018 July 1, 2017 Expires: May 3, 2018 October 30, 2017
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-05 draft-ietf-dtn-bpsec-06
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.
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 http://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 January 2, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 44 skipping to change at page 2, line 44
5.1.2. Receiving BIB Blocks . . . . . . . . . . . . . . . . 21 5.1.2. Receiving BIB Blocks . . . . . . . . . . . . . . . . 21
5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 22 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 22
6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 22 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Policy Considerations . . . . . . . . . . . . . . . 23 7. Security Policy Considerations . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Attacker Capabilities and Objectives . . . . . . . . . . 24 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 24
8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 25 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 25
8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 25 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 25
8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 26 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 26
8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 27 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 27
8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 27 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 28
9. Cipher Suite Authorship Considerations . . . . . . . . . . . 28 9. Cipher Suite Authorship Considerations . . . . . . . . . . . 28
10. Defining Other Security Blocks . . . . . . . . . . . . . . . 29 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 30 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 31 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This document defines security features for the Bundle Protocol (BP) This document defines security features for the Bundle Protocol (BP)
[BPBIS] and is intended for use in Delay Tolerant Networks (DTNs) to [BPBIS] and is intended for use in Delay Tolerant Networks (DTNs) to
provide end-to-end security services. provide end-to-end security services.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
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
decisions for this specification and are necessary for understanding decisions for this specification and are necessary for understanding
the format and behavior of the BPSec protocol. the format and 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
variety of data that may augment or annotate the payload, or variety of data that may augment or annotate the payload, or
otherwise provide information necessary for the proper processing of otherwise provide information necessary for the proper processing of
a bundle along a path. Therefore, applying a single level and type a bundle along a path. Therefore, applying a single level and type
of security across an entire bundle fails to recognize that blocks in of security across an entire bundle fails to recognize that blocks in
skipping to change at page 7, line 39 skipping to change at page 7, line 39
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. For example, a destination node might interpret policy
as it related to security blocks as a function of the security source as it related to security blocks as a function of the security source
for that block. for that block.
2.3. Mixed Security Policy 2.3. Mixed Security Policy
The security policy enforced by nodes in the DTN MAY differ. The security policy enforced by nodes in the DTN MAY differ.
Some waypoints may not be security aware and will not be able to Some waypoints may not be security aware and will not be able to
process security blocks. Therefore, security blocks MUST have their process security blocks. Therefore, security blocks must have their
processing flags set such that the block will be treated processing flags set such that the block will be treated
appropriately by non-security-aware waypoints appropriately by non-security-aware waypoints
Some waypoints will have security policies that require evaluating Some waypoints will have security policies that require evaluating
security services even if they are not the bundle destination or the security services even if they are not the bundle destination or the
final intended destination of the service. For example, a waypoint final intended destination of the service. For example, a waypoint
may choose to verify an integrity service even though the waypoint is may choose to verify an integrity service even though the waypoint is
not the bundle destination and the integrity service will be needed not the bundle destination and the integrity service will be needed
by other node along the bundle's path. by other node along the bundle's path.
skipping to change at page 8, line 20 skipping to change at page 8, line 20
them unless they are the bundle destination. them unless they are the bundle destination.
2.4. User-Selected Cipher Suites 2.4. User-Selected Cipher Suites
The security services defined in this specification rely on a variety The security services defined in this specification rely on a variety
of cipher suites providing integrity signatures, cipher-text, and of cipher suites providing integrity signatures, cipher-text, and
other information necessary to populate security blocks. Users MAY other information necessary to populate security blocks. Users MAY
select different cipher suites to implement security services. For select different cipher suites to implement security services. For
example, some users might prefer a SHA2 hash function for integrity example, some users might prefer a SHA2 hash function for integrity
whereas other users may prefer a SHA3 hash function instead. The whereas other users may prefer a SHA3 hash function instead. 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 identifying what cipher suite has been used to populate
a security block. 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 two types of security block: the Block This specification defines two types of security block: the Block
skipping to change at page 10, line 33 skipping to change at page 10, line 33
block, the information that is common across all operations is block, the information that is common across all operations is
represented once in the security block, and the information which is represented once in the security block, and the information which is
different (e.g., the security targets) are represented individually. different (e.g., the security targets) are represented individually.
When the security block is processed all security operations When the security block is processed all security operations
represented by the security block MUST be applied/evaluated at that represented by the security block MUST be applied/evaluated at that
time. time.
3.4. Target Identification 3.4. Target Identification
A security target is a block in the bundle to which a security A security target is a block in the bundle to which a security
service applies. This target MUST be uniquely and unambiguously service applies. This target must be uniquely and unambiguously
identifiable when processing a security block. The definition of the identifiable when processing a security block. The definition of the
extension block header from [BPBIS] provides a "Block Number" field extension block header from [BPBIS] provides a "Block Number" field
suitable for this purpose. Therefore, a security target in a suitable for this purpose. Therefore, a security target in a
security block MUST be represented as the Block Number of the target security block MUST be represented as the Block Number of the target
block. block.
3.5. Block Representation 3.5. Block Representation
Each security block uses the Canonical Bundle Block Format as defined Each security block uses the Canonical Bundle Block Format as defined
in [BPBIS]. That is, each security block is comprised of the in [BPBIS]. That is, each security block is comprised of the
skipping to change at page 11, line 22 skipping to change at page 11, line 22
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
which they MUST appear. which they must appear.
Security Targets: Security Targets:
This field identifies the block(s) targetted 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.
Cipher Suite Id: Cipher Suite Id:
skipping to change at page 16, line 19 skipping to change at page 16, line 19
about what byte range of the block is actually in any particular about what byte range of the block is actually in any particular
fragment. Therefore, when the security target of a BCB is the bundle fragment. Therefore, when the security target of a BCB is the bundle
payload, the BCB MUST NOT alter the size of the payload block body payload, the BCB MUST NOT alter the size of the payload block body
data. This "in-place" encryption allows fragmentation, reassembly, data. This "in-place" encryption allows fragmentation, reassembly,
and custody transfer to operate without knowledge of whether or not and custody transfer to operate without knowledge of whether or not
encryption has occurred. encryption has occurred.
If a BCB cannot alter the size of the security target (e.g., the If a BCB cannot alter the size of the security target (e.g., the
security target is the payload block or block length modifications security target is the payload block or block length modifications
are disallowed by policy) then differences in the size of the cipher- are disallowed by policy) then differences in the size of the cipher-
text and plain-text MUST be handled in the following way. If the 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 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 used in accordance with the cipher suite policy. If the cipher-text
is larger than the plain-text, overflow bytes MUST be placed in is larger than the plain-text, overflow bytes MUST be placed in
overflow parameters in the Security Result field. overflow parameters in the Security Result field.
Notes: Notes:
o It is RECOMMENDED that cipher suite designers carefully consider o It is RECOMMENDED that cipher suite designers carefully consider
the effect of setting flags that either discard the block or the effect of setting flags that either discard the block or
delete the bundle in the event that this block cannot be delete the bundle in the event that this block cannot be
processed. processed.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
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 confidentiality is being applied to a target that already has If confidentiality is being applied to a target that already has
integrity applied to it, then an undesirable condition occurs where a integrity applied to it, then an undesirable condition occurs where a
security aware waypoint would be unable to check the integrity result security aware waypoint would be unable to check the integrity result
of a block because the block contents have been encrypted after the of a block because the block contents have been encrypted after the
integrity signature was generated. To address this concern, the integrity signature was generated. To address this concern, the
following processing rules MUST be followed. following processing rules must be followed.
o If confidentiality is to be applied to a target, it MUST also be o If confidentiality is to be applied to a target, it MUST also be
applied to any integrity operation already defined for that applied to any integrity operation already defined for that
target. This means that if a BCB is added to encrypt a block, target. This means that if a BCB is added to encrypt a block,
another BCB MUST also be added to encrypt a BIB also targeting another BCB MUST also be added to encrypt a BIB also targeting
that block. that block.
o An integrity operation MUST NOT be applied to a security target if o An integrity operation MUST NOT be applied to a security target if
a BCB in the bundle shares the same security target. This a BCB in the bundle shares the same security target. This
prevents ambiguity in the order of evaluation when receiving a BIB prevents ambiguity in the order of evaluation when receiving a BIB
skipping to change at page 18, line 10 skipping to change at page 18, line 10
definition. definition.
Individual BPSec cipher suites SHOULD use existing registries of Individual BPSec cipher suites SHOULD use existing registries of
identifiers and CBOR encodings, such as those defined in [COSE], identifiers and CBOR encodings, such as those defined in [COSE],
whenever possible. Cipher suites MAY define their own identifiers whenever possible. Cipher suites MAY define their own identifiers
and CBOR encodings when necessary. and CBOR encodings when necessary.
A cipher suite MAY include multiple instances of the same identifier A cipher suite MAY include multiple instances of the same identifier
for a parameter or result in a security block. Parameters and for a parameter or result in a security block. Parameters and
results are represented using CBOR, and any identification of a new results are represented using CBOR, and any identification of a new
parameter or result MUST include how the value will be represented parameter or result must include how the value will be represented
using the CBOR specification. Ids themselves are always represented using the CBOR specification. Ids themselves are always represented
as a CBOR unsigned integer. as a CBOR unsigned integer.
3.11. BSP Block Example 3.11. BSP Block Example
An example of BPSec blocks applied to a bundle is illustrated in An example of BPSec blocks applied to a bundle is illustrated in
Figure 3. In this figure the first column represents blocks within a Figure 3. In this figure the first column represents blocks within a
bundle and the second column represents the Block Number for the bundle and the second column represents the Block Number for the
block, using the terminology B1...Bn for the purpose of illustration. block, using the terminology B1...Bn for the purpose of illustration.
skipping to change at page 20, line 28 skipping to change at page 20, line 28
specification. In the event of conflicting canonicalization specification. In the event of conflicting canonicalization
algorithms, cipher suite algorithms take precedence over this algorithms, cipher suite algorithms take precedence 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.
o All BCB blocks in the bundle MUST be evaluated prior to evaluating o All BCB blocks in the bundle MUST be evaluated prior to evaluating
any BIBs in the bundle. When BIBs and BCBs share a security any BIBs in the bundle. When BIBs and BCBs share a security
target, BCBs MUST be evaluated first and BIBs second. target, BCBs MUST be evaluated first and BIBs second.
5.1.1. Receiving BCB Blocks 5.1.1. Receiving BCB Blocks
If a received bundle contains a BCB, the receiving node MUST If a received bundle contains a BCB, the receiving node must
determine whether it has the responsibility of decrypting the BCB determine whether it has the responsibility of decrypting the BCB
security target and removing the BCB prior to delivering data to an security target and removing the BCB prior to delivering data to an
application at the node or forwarding the bundle. application at the node or forwarding the bundle.
If the receiving node is the destination of the bundle, the node MUST If the receiving node is the destination of the bundle, the node MUST
decrypt any BCBs remaining in the bundle. If the receiving node is decrypt any BCBs remaining in the bundle. If the receiving node is
not the destination of the bundle, the node MAY decrypt the BCB if not the destination of the bundle, the node MAY decrypt the BCB if
directed to do so as a matter of security policy. directed to do so as a matter of security policy.
If the security policy of a security-aware node specifies that a If the security policy of a security-aware node specifies that a
skipping to change at page 21, line 41 skipping to change at page 21, line 41
application at the node or forwarding the bundle. If a BIB check application at the node or forwarding the bundle. If a BIB check
fails, the security target has failed to authenticate and the fails, the security target has failed to authenticate and the
security target SHALL be processed according to the security policy. security target SHALL be processed according to the security policy.
A bundle status report indicating the failure MAY be generated. A bundle status report indicating the failure MAY be generated.
Otherwise, if the BIB verifies, the security target is ready to be Otherwise, if the BIB verifies, the security target is ready to be
processed for delivery. processed for delivery.
A BIB MUST NOT be processed if the security target of the BIB is also A BIB MUST NOT be processed if the security target of the BIB is also
the security target of a BCB in the bundle. Given the order of the security target of a BCB in the bundle. Given the order of
operations mandated by this specification, when both a BIB and a BCB operations mandated by this specification, when both a BIB and a BCB
share a security target, it means that the security target MUST have share a security target, it means that the security target must have
been encrypted after it was integrity signed and, therefore, the BIB been encrypted after it was integrity signed and, therefore, the BIB
cannot be verified until the security target has been decrypted by cannot be verified until the security target has been decrypted by
processing the BCB. processing the BCB.
If the security policy of a security-aware node specifies that a If the security policy of a security-aware node specifies that a
bundle should have applied integrity to a specific security target bundle should have applied integrity to a specific security target
and no such BIB is present in the bundle, then the node MUST process and no such BIB is present in the bundle, then the node MUST process
this security target in accordance with the security policy. This this security target in accordance with the security policy. This
MAY involve removing the security target from the bundle. If the MAY involve removing the security target from the bundle. If the
removed security target is the payload or primary block, the bundle removed security target is the payload or primary block, the bundle
skipping to change at page 23, line 19 skipping to change at page 23, line 19
forwarding, and receipt of bundles that are secured using this forwarding, and receipt of bundles that are secured using this
specification. No single set of policy decisions is envisioned to specification. No single set of policy decisions is envisioned to
work for all secure DTN deployments. work for all secure DTN deployments.
o If a bundle is received that contains more than one security o If a bundle is received that contains more than one security
operation, in violation of BPSec, then the BPA must determine how operation, in violation of BPSec, then the BPA must determine how
to handle this bundle. The bundle may be discarded, the block to handle this bundle. The bundle may be discarded, the block
affected by the security operation may be discarded, or one affected by the security operation may be discarded, or one
security operation may be favored over another. security operation may be favored over another.
o BPAs in the network MUST understand what security operations they o BPAs in the network must understand what security operations they
should apply to bundles. This decision may be based on the source should apply to bundles. This decision may be based on the source
of the bundle, the destination of the bundle, or some other of the bundle, the destination of the bundle, or some other
information related to the bundle. information related to the bundle.
o If a waypoint has been configured to add a security operation to a o If a waypoint has been configured to add a security operation to a
bundle, and the received bundle already has the security operation bundle, and the received bundle already has the security operation
applied, then the receiver MUST understand what to do. The applied, then the receiver must understand what to do. The
receiver may discard the bundle, discard the security target and receiver may discard the bundle, discard the security target and
associated BPSec blocks, replace the security operation, or some associated BPSec blocks, replace the security operation, or some
other action. other action.
o It is recommended that security operations only be applied to the o It is recommended that security operations only be applied to the
blocks that absolutely need them. If a BPA were to apply security blocks that absolutely need them. If a BPA were to apply security
operations such as integrity or confidentiality to every block in operations such as integrity or confidentiality to every block in
the bundle, regardless of need, there could be downstream errors the bundle, regardless of need, there could be downstream errors
processing blocks whose contents must be inspected or changed at processing blocks whose contents must be inspected or changed at
every hop along the path. every hop along the path.
skipping to change at page 26, line 7 skipping to change at page 26, line 7
cryptographic keying material from the blocks contained within. The cryptographic keying material from the blocks contained within. The
protection mechanism that BPSec provides against this action is the protection mechanism that BPSec provides against this action is the
BCB, which encrypts the contents of its security target, providing BCB, which encrypts the contents of its security target, providing
confidentiality of the data. Of course, it should be assumed that confidentiality of the data. Of course, it should be assumed that
Mallory is able to attempt offline recovery of encrypted data, so the Mallory is able to attempt offline recovery of encrypted data, so the
cryptographic mechanisms selected to protect the data should provide cryptographic mechanisms selected to protect the data should provide
a suitable level of protection. a suitable level of protection.
When evaluating the risk of eavesdropping attacks, it is important to When evaluating the risk of eavesdropping attacks, it is important to
consider the lifetime of bundles on a DTN. Depending on the network, consider the lifetime of bundles on a DTN. Depending on the network,
bundles may persist for days or even years. If a bundle does persist bundles may persist for days or even years. Long-lived bundles imply
on the network for years and the cipher suite used for a BCB provides that the data exists in the network for a longer period of time and,
inadequate protection, Mallory may be able to recover the protected thus, there may be more opportunities to capture those bundles.
data before that bundle reaches its intended destination. Additionally, bundles that are long-lived imply that the information
stored within them may remain relevant and sensitive for long enough
that, once captured, there is sufficient time to crack encryption
associated with the bundle. If a bundle does persist on the network
for years and the cipher suite used for a BCB provides inadequate
protection, Mallory may be able to recover the protected data either
before that bundle reaches its intended destination or before the
information in the bundle is no longer considered sensitive.
8.2.2. Modification Attacks 8.2.2. Modification Attacks
As a node participating in the DTN between Alice and Bob, Mallory As a node participating in the DTN between Alice and Bob, Mallory
will also be able to modify the received bundle, including non-BPSec will also be able to modify the received bundle, including non-BPSec
data such as the primary block, payload blocks, or block processing data such as the primary block, payload blocks, or block processing
control flags as defined in [BPBIS]. Mallory will be able to control flags as defined in [BPBIS]. Mallory will be able to
undertake activities which include modification of data within the undertake activities which include modification of data within the
blocks, replacement of blocks, addition of blocks, or removal of blocks, replacement of blocks, addition of blocks, or removal of
blocks. Within BPSec, both the BIB and BCB provide integrity blocks. Within BPSec, both the BIB and BCB provide integrity
skipping to change at page 26, line 44 skipping to change at page 26, line 51
a bundle, there is no in-band mechanism for detecting or correcting a bundle, there is no in-band mechanism for detecting or correcting
certain cases where Mallory removes blocks from a bundle. If Mallory certain cases where Mallory removes blocks from a bundle. If Mallory
removes a BCB block, but keeps the security target, the security removes a BCB block, but keeps the security target, the security
target remains encrypted and there is a possibility that there may no target remains encrypted and there is a possibility that there may no
longer be sufficient information to decrypt the block at its longer be sufficient information to decrypt the block at its
destination. If Mallory removes both a BCB (or BIB) and its security destination. If Mallory removes both a BCB (or BIB) and its security
target there is no evidence left in the bundle of the security target there is no evidence left in the bundle of the security
operation. Similarly, if Mallory removes the BIB but not the operation. Similarly, if Mallory removes the BIB but not the
security target there is no evidence left in the bundle of the security target there is no evidence left in the bundle of the
security operation. In each of these cases, the implementation of security operation. In each of these cases, the implementation of
BPSec MUST be combined with policy configuration at endpoints in the BPSec must be combined with policy configuration at endpoints in the
network which describe the expected and required security operations network which describe the expected and required security operations
that must be applied on transmission and are expected to be present that must be applied on transmission and are expected to be present
on receipt. This or other similar out-of-band information is on receipt. This or other similar out-of-band information is
required to correct for removal of security information in the required to correct for removal of security information in the
bundle. bundle.
A limitation of the BIB may exist within the implementation of BIB A limitation of the BIB may exist within the implementation of BIB
validation at the destination node. If Mallory is a legitimate node validation at the destination node. If Mallory is a legitimate node
within the DTN, the BIB generated by Alice with K_A can be replaced within the DTN, the BIB generated by Alice with K_A can be replaced
with a new BIB generated with K_M and forwarded to Bob. If Bob is with a new BIB generated with K_M and forwarded to Bob. If Bob is
only validating that the BIB was generated by a legitimate user, Bob only validating that the BIB was generated by a legitimate user, Bob
will acknowledge the message as originating from Mallory instead of will acknowledge the message as originating from Mallory instead of
Alice. In order to provide verifiable integrity checks, both a BIB Alice. In order to provide verifiable integrity checks, both a BIB
and BCB should be used. Alice creates a BIB with the protected data and BCB should be used and the BCB should require an IND-CCA2
block as the security target and then creates a BCB with both the BIB encryption scheme. Such an encryption scheme will guard against
and protected data block as its security targets. In this signature substitution attempts by Mallory. In this case, Alice
configuration, since Mallory is only a legitimate node and does not creates a BIB with the protected data block as the security target
have access to Alice's key K_A, Mallory is unable to decrypt the BCB and then creates a BCB with both the BIB and protected data block as
and replace the BIB. its security targets.
8.2.3. Topology Attacks 8.2.3. Topology Attacks
If Mallory is in a MITM position within the DTN, she is able to If Mallory is in a MITM position within the DTN, she is able to
influence how any bundles that come to her may pass through the influence how any bundles that come to her may pass through the
network. Upon receiving and processing a bundle that must be routed network. Upon receiving and processing a bundle that must be routed
elsewhere in the network, Mallory has three options as to how to elsewhere in the network, Mallory has three options as to how to
proceed: not forward the bundle, forward the bundle as intended, or proceed: not forward the bundle, forward the bundle as intended, or
forward the bundle to one or more specific nodes within the network. forward the bundle to one or more specific nodes within the network.
skipping to change at page 29, line 45 skipping to change at page 30, line 8
o An OSB definition MUST provide a canonicalization algorithm if the o An OSB definition MUST provide a canonicalization algorithm if the
default non-primary-block canonicalization algorithm cannot be default non-primary-block canonicalization algorithm cannot be
used to generate a deterministic input for a cipher suite. This used to generate a deterministic input for a cipher suite. This
requirement MAY be waived if the OSB is defined so as to never be requirement MAY be waived if the OSB is defined so as to never be
the security target of a BIB or a BCB. the security target of a BIB or a BCB.
o An OSB definition MAY NOT require any behavior of a BPSEC-BPA that o An OSB definition MAY NOT require any behavior of a BPSEC-BPA that
is in conflict with the behavior identified in this specification. is in conflict with the behavior identified in this specification.
In particular, the security processing requirements imposed by In particular, the security processing requirements imposed by
this specification MUST be consistent across all BPSEC-BPAs in a this specification must be consistent across all BPSEC-BPAs in a
network. network.
o The behavior of an OSB when dealing with fragmentation MUST be o The behavior of an OSB when dealing with fragmentation must be
specified and MUST NOT lead to ambiguous processing states. In specified and MUST NOT lead to ambiguous processing states. In
particular, an OSB definition should address how to receive and particular, an OSB definition should address how to receive and
process an OSB in a bundle fragment that may or may not also process an OSB in a bundle fragment that may or may not also
contain its security target. An OSB definition should also contain its security target. An OSB definition should also
address whether an OSB may be added to a bundle marked as a address whether an OSB may be added to a bundle marked as a
fragment. fragment.
Additionally, policy considerations for the management, monitoring, Additionally, policy considerations for the management, monitoring,
and configuration associated with blocks SHOULD be included in any and configuration associated with blocks SHOULD be included in any
OSB definition. OSB definition.
skipping to change at page 30, line 49 skipping to change at page 31, line 15
[BPBIS] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol", [BPBIS] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol",
draft-ietf-dtn-bpbis-06 (work in progress), July 2016. draft-ietf-dtn-bpbis-06 (work in progress), July 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol
IANA Registries", RFC 6255, May 2011. IANA Registries", RFC 6255, May 2011.
12.2. Informative References 12.2. Informative References
[COSE] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [COSE] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
draft-ietf-cose-msg-24 (work in progress), November 2016. draft-ietf-cose-msg-24 (work in progress), November 2016.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
 End of changes. 28 change blocks. 
37 lines changed or deleted 44 lines changed or added

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