draft-ietf-dtn-bpsec-24.txt   draft-ietf-dtn-bpsec-25.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: May 5, 2021 November 1, 2020 Expires: June 4, 2021 December 1, 2020
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-24 draft-ietf-dtn-bpsec-25
Abstract Abstract
This document defines a security protocol providing data integrity This document defines a security protocol providing data integrity
and confidentiality services for the Bundle Protocol. and confidentiality services for the Bundle Protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 5, 2021. This Internet-Draft will expire on June 4, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 30, line 15 skipping to change at page 30, line 15
threat models and describe the roles and responsibilities of the threat models and describe the roles and responsibilities of the
BPSec protocol in protecting the confidentiality and integrity of the BPSec protocol in protecting the confidentiality and integrity of the
data against those threats. This section provides additional data against those threats. This section provides additional
discussion on security threats that BPSec will face and describes how discussion on security threats that BPSec will face and describes how
BPSec security mechanisms operate to mitigate these threats. BPSec security mechanisms operate to mitigate these threats.
The threat model described here is assumed to have a set of The threat model described here is assumed to have a set of
capabilities identical to those described by the Internet Threat capabilities identical to those described by the Internet Threat
Model in [RFC3552], but the BPSec threat model is scoped to Model in [RFC3552], but the BPSec threat model is scoped to
illustrate threats specific to BPSec operating within DTN illustrate threats specific to BPSec operating within DTN
environments and therefore focuses on man-in-the-middle (MITM) environments and therefore focuses on on-path-attackers (OPAs). In
attackers. In doing so, it is assumed that the DTN (or significant doing so, it is assumed that the DTN (or significant portions of the
portions of the DTN) are completely under the control of an attacker. DTN) are completely under the control of an attacker.
8.1. Attacker Capabilities and Objectives 8.1. Attacker Capabilities and Objectives
BPSec was designed to protect against MITM threats which may have BPSec was designed to protect against OPA threats which may have
access to a bundle during transit from its source, Alice, to its access to a bundle during transit from its source, Alice, to its
destination, Bob. A MITM node, Mallory, is a non-cooperative node destination, Bob. An OPA node, Olive, is a non-cooperative node
operating on the DTN between Alice and Bob that has the ability to operating on the DTN between Alice and Bob that has the ability to
receive bundles, examine bundles, modify bundles, forward bundles, receive bundles, examine bundles, modify bundles, forward bundles,
and generate bundles at will in order to compromise the and generate bundles at will in order to compromise the
confidentiality or integrity of data within the DTN. There are three confidentiality or integrity of data within the DTN. There are three
classes of MITM nodes which are differentiated based on their access classes of OPA nodes which are differentiated based on their access
to cryptographic material: to cryptographic material:
o Unprivileged Node: Mallory has not been provisioned within the o Unprivileged Node: Olive has not been provisioned within the
secure environment and only has access to cryptographic material secure environment and only has access to cryptographic material
which has been publicly-shared. which has been publicly-shared.
o Legitimate Node: Mallory is within the secure environment and o Legitimate Node: Olive is within the secure environment and
therefore has access to cryptographic material which has been therefore has access to cryptographic material which has been
provisioned to Mallory (i.e., K_M) as well as material which has provisioned to Olive (i.e., K_M) as well as material which has
been publicly-shared. been publicly-shared.
o Privileged Node: Mallory is a privileged node within the secure o Privileged Node: Olive is a privileged node within the secure
environment and therefore has access to cryptographic material environment and therefore has access to cryptographic material
which has been provisioned to Mallory, Alice and/or Bob (i.e. which has been provisioned to Olive, Alice and/or Bob (i.e. K_M,
K_M, K_A, and/or K_B) as well as material which has been publicly- K_A, and/or K_B) as well as material which has been publicly-
shared. shared.
If Mallory is operating as a privileged node, this is tantamount to If Olive is operating as a privileged node, this is tantamount to
compromise; BPSec does not provide mechanisms to detect or remove compromise; BPSec does not provide mechanisms to detect or remove
Mallory from the DTN or BPSec secure environment. It is up to the Olive from the DTN or BPSec secure environment. It is up to the
BPSec implementer or the underlying cryptographic mechanisms to BPSec implementer or the underlying cryptographic mechanisms to
provide appropriate capabilities if they are needed. It should also provide appropriate capabilities if they are needed. It should also
be noted that if the implementation of BPSec uses a single set of be noted that if the implementation of BPSec uses a single set of
shared cryptographic material for all nodes, a legitimate node is shared cryptographic material for all nodes, a legitimate node is
equivalent to a privileged node because K_M == K_A == K_B. For this equivalent to a privileged node because K_M == K_A == K_B. For this
reason, sharing cryptographic material in this way is not reason, sharing cryptographic material in this way is not
recommended. recommended.
A special case of the legitimate node is when Mallory is either Alice A special case of the legitimate node is when Olive is either Alice
or Bob (i.e., K_M == K_A or K_M == K_B). In this case, Mallory is or Bob (i.e., K_M == K_A or K_M == K_B). In this case, Olive is able
able to impersonate traffic as either Alice or Bob, respectively, to impersonate traffic as either Alice or Bob, respectively, which
which means that traffic to and from that node can be decrypted and means that traffic to and from that node can be decrypted and
encrypted, respectively. Additionally, messages may be signed as encrypted, respectively. Additionally, messages may be signed as
originating from one of the endpoints. originating from one of the endpoints.
8.2. Attacker Behaviors and BPSec Mitigations 8.2. Attacker Behaviors and BPSec Mitigations
8.2.1. Eavesdropping Attacks 8.2.1. Eavesdropping Attacks
Once Mallory has received a bundle, she is able to examine the Once Olive has received a bundle, she is able to examine the contents
contents of that bundle and attempt to recover any protected data or of that bundle and attempt to recover any protected data or
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 Olive 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. Long-lived bundles imply bundles may persist for days or even years. Long-lived bundles imply
that the data exists in the network for a longer period of time and, that the data exists in the network for a longer period of time and,
thus, there may be more opportunities to capture those bundles. thus, there may be more opportunities to capture those bundles.
Additionally, bundles that are long-lived imply that the information Additionally, bundles that are long-lived imply that the information
stored within them may remain relevant and sensitive for long enough stored within them may remain relevant and sensitive for long enough
that, once captured, there is sufficient time to crack encryption that, once captured, there is sufficient time to crack encryption
associated with the bundle. If a bundle does persist on the network associated with the bundle. If a bundle does persist on the network
for years and the cipher suite used for a BCB provides inadequate for years and the cipher suite used for a BCB provides inadequate
protection, Mallory may be able to recover the protected data either protection, Olive may be able to recover the protected data either
before that bundle reaches its intended destination or before the before that bundle reaches its intended destination or before the
information in the bundle is no longer considered sensitive. information in the bundle is no longer considered sensitive.
NOTE: Mallory is not limited by the bundle lifetime and may retain a NOTE: Olive is not limited by the bundle lifetime and may retain a
given bundle indefinitely. given bundle indefinitely.
NOTE: Irrespective of whether BPSec is used, traffic analysis will be NOTE: Irrespective of whether BPSec is used, traffic analysis will be
possible. possible.
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, Olive will
will also be able to modify the received bundle, including non-BPSec also be able to modify the received bundle, including non-BPSec data
data such as the primary block, payload blocks, or block processing such as the primary block, payload blocks, or block processing
control flags as defined in [I-D.ietf-dtn-bpbis]. Mallory will be control flags as defined in [I-D.ietf-dtn-bpbis]. Olive will be able
able to undertake activities which include modification of data to undertake activities which include modification of data within the
within the blocks, replacement of blocks, addition of blocks, or blocks, replacement of blocks, addition of blocks, or removal of
removal of blocks. Within BPSec, both the BIB and BCB provide blocks. Within BPSec, both the BIB and BCB provide integrity
integrity protection mechanisms to detect or prevent data protection mechanisms to detect or prevent data manipulation attempts
manipulation attempts by Mallory. by Olive.
The BIB provides that protection to another block which is its The BIB provides that protection to another block which is its
security target. The cryptographic mechanisms used to generate the security target. The cryptographic mechanisms used to generate the
BIB should be strong against collision attacks and Mallory should not BIB should be strong against collision attacks and Olive should not
have access to the cryptographic material used by the originating have access to the cryptographic material used by the originating
node to generate the BIB (e.g., K_A). If both of these conditions node to generate the BIB (e.g., K_A). If both of these conditions
are true, Mallory will be unable to modify the security target or the are true, Olive will be unable to modify the security target or the
BIB and lead Bob to validate the security target as originating from BIB and lead Bob to validate the security target as originating from
Alice. Alice.
Since BPSec security operations are implemented by placing blocks in Since BPSec security operations are implemented by placing blocks in
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 Olive removes blocks from a bundle. If Olive
removes a BCB, but keeps the security target, the security target removes a BCB, but keeps the security target, the security target
remains encrypted and there is a possibility that there may no longer remains encrypted and there is a possibility that there may no longer
be sufficient information to decrypt the block at its destination. be sufficient information to decrypt the block at its destination.
If Mallory removes both a BCB (or BIB) and its security target there If Olive removes both a BCB (or BIB) and its security target there is
is no evidence left in the bundle of the security operation. no evidence left in the bundle of the security operation. Similarly,
Similarly, if Mallory removes the BIB but not the security target if Olive removes the BIB but not the security target there is no
there is no evidence left in the bundle of the security operation. evidence left in the bundle of the security operation. In each of
In each of these cases, the implementation of BPSec must be combined these cases, the implementation of BPSec must be combined with policy
with policy configuration at endpoints in the network which describe configuration at endpoints in the network which describe the expected
the expected and required security operations that must be applied on and required security operations that must be applied on transmission
transmission and are expected to be present on receipt. This or and are expected to be present on receipt. This or other similar
other similar out-of-band information is required to correct for out-of-band information is required to correct for removal of
removal of security information in the bundle. security information in the 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 Olive 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 Olive instead of
Alice. Validating a BIB indicates only that the BIB was generated by Alice. Validating a BIB indicates only that the BIB was generated by
a holder of the relevant key; it does not provide any guarantee that a holder of the relevant key; it does not provide any guarantee that
the bundle or block was created by the same entity. In order to the bundle or block was created by the same entity. In order to
provide verifiable integrity checks BCB should require an encryption provide verifiable integrity checks BCB should require an encryption
scheme that is Indistinguishable under adaptive Chosen Ciphertext scheme that is Indistinguishable under adaptive Chosen Ciphertext
Attack (IND-CCA2) secure. Such an encryption scheme will guard Attack (IND-CCA2) secure. Such an encryption scheme will guard
against signature substitution attempts by Mallory. In this case, against signature substitution attempts by Olive. In this case,
Alice creates a BIB with the protected data block as the security Alice creates a BIB with the protected data block as the security
target and then creates a BCB with both the BIB and protected data target and then creates a BCB with both the BIB and protected data
block as its security targets. block as 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 Olive is in a OPA 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, Olive 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.
Attacks that involve re-routing the packets throughout the network Attacks that involve re-routing the packets throughout the network
are essentially a special case of the modification attacks described are essentially a special case of the modification attacks described
in this section where the attacker is modifying fields within the in this section where the attacker is modifying fields within the
primary block of the bundle. Given that BPSec cannot encrypt the primary block of the bundle. Given that BPSec cannot encrypt the
contents of the primary block, alternate methods must be used to contents of the primary block, alternate methods must be used to
prevent this situation. These methods may include requiring BIBs for prevent this situation. These methods may include requiring BIBs for
primary blocks, using encapsulation, or otherwise strategically primary blocks, using encapsulation, or otherwise strategically
skipping to change at page 33, line 38 skipping to change at page 33, line 38
mitigation technique are specific to the implementation of the mitigation technique are specific to the implementation of the
deploying network and outside of the scope of this document. deploying network and outside of the scope of this document.
Furthermore, routing rules and policies may be useful in enforcing Furthermore, routing rules and policies may be useful in enforcing
particular traffic flows to prevent topology attacks. While these particular traffic flows to prevent topology attacks. While these
rules and policies may utilize some features provided by BPSec, their rules and policies may utilize some features provided by BPSec, their
definition is beyond the scope of this specification. definition is beyond the scope of this specification.
8.2.4. Message Injection 8.2.4. Message Injection
Mallory is also able to generate new bundles and transmit them into Olive is also able to generate new bundles and transmit them into the
the DTN at will. These bundles may either be copies or slight DTN at will. These bundles may either be copies or slight
modifications of previously-observed bundles (i.e., a replay attack) modifications of previously-observed bundles (i.e., a replay attack)
or entirely new bundles generated based on the Bundle Protocol, or entirely new bundles generated based on the Bundle Protocol,
BPSec, or other bundle-related protocols. With these attacks BPSec, or other bundle-related protocols. With these attacks Olive's
Mallory's objectives may vary, but may be targeting either the bundle objectives may vary, but may be targeting either the bundle protocol
protocol or application-layer protocols conveyed by the bundle or application-layer protocols conveyed by the bundle protocol. The
protocol. The target could also be the storage and compute of the target could also be the storage and compute of the nodes running the
nodes running the bundle or application layer protocols (e.g., a bundle or application layer protocols (e.g., a denial of service to
denial of service to flood on the storage of the store-and-forward flood on the storage of the store-and-forward mechanism; or compute
mechanism; or compute which would process the packets and perhaps which would process the packets and perhaps prevent other
prevent other activities). activities).
BPSec relies on cipher suite capabilities to prevent replay or forged BPSec relies on cipher suite capabilities to prevent replay or forged
message attacks. A BCB used with appropriate cryptographic message attacks. A BCB used with appropriate cryptographic
mechanisms may provide replay protection under certain circumstances. mechanisms may provide replay protection under certain circumstances.
Alternatively, application data itself may be augmented to include Alternatively, application data itself may be augmented to include
mechanisms to assert data uniqueness and then protected with a BIB, a mechanisms to assert data uniqueness and then protected with a BIB, a
BCB, or both along with other block data. In such a case, the BCB, or both along with other block data. In such a case, the
receiving node would be able to validate the uniqueness of the data. receiving node would be able to validate the uniqueness of the data.
For example, a BIB may be used to validate the integrity of a For example, a BIB may be used to validate the integrity of a
skipping to change at page 40, line 14 skipping to change at page 40, line 14
11.3. Security Context Identifiers 11.3. Security Context Identifiers
BPSec has a Security Context Identifier field for which IANA is BPSec has a Security Context Identifier field for which IANA is
requested to create and maintain a new registry named "BPSec Security requested to create and maintain a new registry named "BPSec Security
Context Identifiers". Initial values for this registry are given Context Identifiers". Initial values for this registry are given
below. below.
The registration policy for this registry is: Specification Required. The registration policy for this registry is: Specification Required.
The value range is: unsigned 16-bit integer. The value range is: signed 16-bit integer.
BPSec Security Context Identifier Registry BPSec Security Context Identifier Registry
+-------+-------------+---------------+ +-------+-------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------+---------------+ +-------+-------------+---------------+
| < 0 | Reserved | This document | | < 0 | Reserved | This document |
| 0 | Reserved | This document | | 0 | Reserved | This document |
+-------+-------------+---------------+ +-------+-------------+---------------+
 End of changes. 32 change blocks. 
64 lines changed or deleted 64 lines changed or added

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