--- 1/draft-ietf-dtn-bpsec-13.txt 2020-01-16 09:13:15.367986669 -0800 +++ 2/draft-ietf-dtn-bpsec-14.txt 2020-01-16 09:13:15.447988738 -0800 @@ -1,110 +1,116 @@ Delay-Tolerant Networking E. Birrane Internet-Draft K. McKeever -Intended status: Standards Track JHU/APL -Expires: May 7, 2020 November 4, 2019 +Obsoletes: 6257 (if approved) JHU/APL +Intended status: Standards Track January 16, 2020 +Expires: July 19, 2020 Bundle Protocol Security Specification - draft-ietf-dtn-bpsec-13 + draft-ietf-dtn-bpsec-14 Abstract This document defines a security protocol providing end to end data integrity and confidentiality services for the Bundle Protocol. + The Internet Research Task Force is advised that this document is an + update of the protocol described in [RFC6257], reflecting lessons + learned. The Internet Research Task Force is requested to mark + [RFC6257] as obsolete. + Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 7, 2020. + This Internet-Draft will expire on July 19, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Supported Security Services . . . . . . . . . . . . . . . 3 + 1.1. Supported Security Services . . . . . . . . . . . . . . . 4 1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4 1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 7 2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9 - 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 + 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 10 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11 - 3.4. Target Identification . . . . . . . . . . . . . . . . . . 11 + 3.4. Target Identification . . . . . . . . . . . . . . . . . . 12 3.5. Block Representation . . . . . . . . . . . . . . . . . . 12 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17 3.10. Parameter and Result Identification . . . . . . . . . . . 18 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 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 - 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22 - 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22 - 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23 - 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23 - 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24 - 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 25 - 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 25 - 7. Security Policy Considerations . . . . . . . . . . . . . . . 25 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 27 - 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 28 - 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 28 - 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29 - 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30 - 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 30 - 9. Security Context Considerations . . . . . . . . . . . . . . . 31 - 9.1. Identification and Configuration . . . . . . . . . . . . 31 - 9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 31 - 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 33 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 - 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 34 - 11.2. Security Context Identifiers . . . . . . . . . . . . . . 34 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 - 12.2. Informative References . . . . . . . . . . . . . . . . . 35 - Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 + 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 20 + 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 21 + 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 21 + 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 21 + 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 22 + 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 23 + 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 24 + 7. Security Policy Considerations . . . . . . . . . . . . . . . 24 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 26 + 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 27 + 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 27 + 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 27 + 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 28 + 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 29 + 9. Security Context Considerations . . . . . . . . . . . . . . . 29 + 9.1. Identification and Configuration . . . . . . . . . . . . 29 + 9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 30 + 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 32 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 33 + 11.2. Security Context Identifiers . . . . . . . . . . . . . . 33 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 + 12.2. Informative References . . . . . . . . . . . . . . . . . 34 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction This document defines security features for the Bundle Protocol (BP) [I-D.ietf-dtn-bpbis] and is intended for use in Delay Tolerant Networks (DTNs) to provide end-to-end security services. The Bundle Protocol specification [I-D.ietf-dtn-bpbis] defines DTN as referring to "a networking architecture providing communications in and/or through highly stressed environments" where "BP may be viewed @@ -121,20 +127,25 @@ transport security mechanisms may not be sufficient. For example, the store-carry-forward nature of the network may require protecting data at rest, preventing unauthorized consumption of critical resources such as storage space, and operating without regular contact with a centralized security oracle (such as a certificate authority). An end-to-end security service is needed that operates in all of the environments where the BP operates. + The Internet Research Task Force is advised that this document is an + update of the protocol described in [RFC6257], reflecting lessons + learned. The Internet Research Task Force is requested to mark + [RFC6257] as obsolete. + 1.1. Supported Security Services BPSec provides end-to-end integrity and confidentiality services for BP bundles, as defined in this section. Integrity services ensure that changes to target data within a bundle can be discovered. Data changes may be caused by processing errors, environmental conditions, or intentional manipulation. In the context of BPSec, integrity services apply to plain-text in the bundle. @@ -249,21 +260,21 @@ "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This section defines terminology either unique to the BPSec or otherwise necessary for understanding the concepts defined in this specification. 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 Bundle Protocol Agent (BPA) receiving the bundle. The bundle - destination acts as the security destination for every security + destination acts as the security acceptor for every security target in every security block in every bundle it receives. o Bundle Source - the node which originates a bundle. Also, the Node ID of the BPA originating the bundle. o Cipher Suite - a set of one or more algorithms providing integrity and confidentiality services. Cipher suites may define necessary parameters but do not provide values for those parameters. o Forwarder - any node that transmits a bundle in the DTN. Also, @@ -271,28 +282,29 @@ hop. o Intermediate Receiver, Waypoint, or Next Hop - any node that receives a bundle from a Forwarder that is not the Bundle Destination. Also, the Node ID of the BPA at any such node. o Path - the ordered sequence of nodes through which a bundle passes on its way from Source to Destination. The path is not necessarily known in advance by the bundle or any BPAs in the DTN. + o Security Acceptor - a bundle node that processes and dispositions + one or more security blocks in a bundle. Also, the Node ID of + that node. + o Security Block - a BPSec extension block in a bundle. o Security Context - the set of assumptions, algorithms, configurations and policies used to implement security services. - o Security Destination - a bundle node that processes one or more - security blocks in a bundle. Also, the Node ID of that node. - o Security Operation - the application of a security service to a security target, notated as OP(security service, security target). For example, OP(confidentiality, payload). Every security operation in a bundle MUST be unique, meaning that a security service can only be applied to a security target once in a bundle. A security operation is implemented by a security block. o Security Service - the security features supported by this specification: either integrity or confidentiality. @@ -364,21 +376,21 @@ The security policy enforced by nodes in the DTN may differ. Some waypoints might not be security aware and will not be able to process security blocks. Therefore, security blocks must have their processing flags set such that the block will be treated appropriately by non-security-aware waypoints. Some waypoints will have security policies that require evaluating security services even if they are not the bundle destination or the - final intended destination of the service. For example, a waypoint + final intended acceptor of the service. For example, a waypoint could choose to verify an integrity service even though the waypoint is not the bundle destination and the integrity service will be needed by other nodes along the bundle's path. Some waypoints will determine, through policy, that they are the intended recipient of the security service and terminate the security service in the bundle. For example, a gateway node could determine that, even though it is not the destination of the bundle, it should verify and remove a particular integrity service or attempt to decrypt a confidentiality service, before forwarding the bundle along @@ -501,26 +513,26 @@ When representing multiple security operations in a single security block, the information that is common across all operations is represented once in the security block, and the information which is different (e.g., the security targets) are represented individually. It is RECOMMENDED that if a node processes any security operation in a security block that it process all security operations in the security block. This allows security sources to assert that the set of security operations in a security block are expected to be - processed by the same security destination. However, the - determination of whether a node actually is a security destination or - not is a matter of the policy of the node itself. In cases where a - receiving node determines that it is the security destination of only - a subset of the security operations in a security block, the node may - choose to only process that subset of security operations. + processed by the same security acceptor. However, the determination + of whether a node actually is a security acceptor or not is a matter + of the policy of the node itself. In cases where a receiving node + determines that it is the security acceptor of only a subset of the + security operations in a security block, the node may choose to only + process that subset of security operations. 3.4. Target Identification A security target is a block in the bundle to which a security service applies. This target must be uniquely and unambiguously identifiable when processing a security block. The definition of the extension block header from [I-D.ietf-dtn-bpbis] provides a "Block Number" field suitable for this purpose. Therefore, a security target in a security block MUST be represented as the Block Number of the target block. @@ -624,26 +636,20 @@ in Section 3.10. * Parameter Value. This field captures the value associated with this parameter. This field SHALL be represented by the applicable CBOR representation of the parameter, in accordance with Section 3.10. The logical layout of the parameters array is illustrated in Figure 1. - +----------------+----------------+ +----------------+ - | Parameter 1 | Parameter 2 | ... | Parameter N | - +------+---------+------+---------+ +------+---------+ - | Id | Value | Id | Value | | Id | Value | - +------+---------+------+---------+ +------+---------+ - Figure 1: Security Context Parameters Security Results: This field captures the results of applying a security service to the security targets of the security block. This field SHALL be represented as a CBOR array of target results. Each entry in this array represents the set of security results for a specific security target. The target results MUST be ordered identically to the Security Targets field of the security block. This means that the first set of target results in this @@ -668,68 +674,60 @@ * Result Value. This field captures the value associated with the result. This field SHALL be represented by the applicable CBOR representation of the result value, in accordance with Section 3.10. The logical layout of the security results array is illustrated in Figure 2. In this figure there are N security targets for this security block. The first security target contains M results and the Nth security target contains K results. - +------------------------------+ +------------------------------+ - | Target 1 | | Target N | - +------------+----+------------+ +------------------------------+ - | Result 1 | | Result M | ... | Result 1 | | Result K | - +----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+ - | Id | Value | | Id | Value | | Id | Value | | Id | Value | - +----+-------+ +----+-------+ +----+-------+ +----+-------+ - Figure 2: Security Results 3.7. Block Integrity Block A BIB is a bundle extension block with the following characteristics. o The Block Type Code value is as specified in Section 11.1. o The Block Type Specific Data Fields follow the structure of the ASB. o A security target listed in the Security Targets field MUST NOT reference a security block defined in this specification (e.g., a BIB or a BCB). o The Security Context Id MUST utilize an end-to-end authentication cipher or an end-to-end error detection cipher. - 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 - be inferred according to security policy and MAY default to the + o The EID of the security source MAY be present. If this field is + not present, then the security source of the block SHOULD be + inferred according to security policy and MAY default to the bundle source. The security source MAY be specified as part of security context information described in Section 3.10. Notes: o It is RECOMMENDED that designers carefully consider the effect of setting flags that either discard the block or delete the bundle in the event that this block cannot be processed. o Since OP(integrity, target) is allowed only once in a bundle per target, it is RECOMMENDED that users wishing to support multiple integrity signatures for the same target define a multi-signature security context. o For some security contexts, (e.g., those using asymmetric keying to produce signatures or those using symmetric keying with a group key), the security information MAY be checked at any hop on the - way to the destination that has access to the required keying - information, in accordance with Section 3.9. + way to the bundle destination that has access to the required + keying information, in accordance with Section 3.9. 3.8. Block Confidentiality Block 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 Processing Control flags value can be set to whatever values are required by local policy, except that this block MUST have the "replicate in every fragment" flag set if the target of @@ -747,23 +745,23 @@ The Security Context Id MUST utilize a confidentiality cipher that provides authenticated encryption with associated data (AEAD). Additional information created by a cipher suite (such as additional authenticated data) can be placed either in a security result field or in the generated cipher-text. The determination of where to place these data is a function of the cipher suite and security context used. - An EID-reference to the security source MAY be present. If this - field is not present, then the security source of the block SHOULD - be inferred according to security policy and MAY default to the + The EID of the security source MAY be present. If this field is + not present, then the security source of the block SHOULD be + inferred according to security policy and MAY default to the bundle source. The security source MAY be specified as part of security context information described in Section 3.10. The BCB modifies the contents of its security target(s). When a BCB is applied, the security target body data are encrypted "in-place". Following encryption, the security target Block Type Specific Data field contains cipher-text, not plain-text. Other block fields remain unmodified, with the exception of the Block Data Length field, which MUST be updated to reflect the new length of the Block Type Specific Data field. @@ -830,27 +828,27 @@ security target. These restrictions on block interactions impose a necessary ordering when applying security operations within a bundle. Specifically, for a given security target, BIBs MUST be added before BCBs. This 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 waypoint adding new security blocks to a bundle that already contains security blocks. - 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 - 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 - integrity mechanism and encrypt a security target, a BCB with a - security context that generates such signatures as additional - security results SHOULD be used instead. + Since any cipher suite used with a BCB MUST be an AEAD cipher suite, + it is inefficient and insecure for a single security 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 integrity + mechanism and encrypt a security target, a BCB with a security + context that generates such signatures as additional security results + MUST be used instead. 3.10. Parameter and Result Identification Each security context MUST define its own context parameters and results. Each defined parameter and result is represented as the tuple of an identifier and a value. Identifiers are always represented as a CBOR unsigned integer. The CBOR encoding of values is as defined by the security context specification. Identifiers MUST be unique for a given security context but do not @@ -871,37 +869,20 @@ In this example a bundle has four non-security-related blocks: the primary block (B1), two extension blocks (B4,B5), and a payload block (B6). The bundle source wishes to provide an integrity signature of the plain-text associated with the primary block, the second extension block, and the payload. The bundle source also wishes to 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 - +======================================+====+ - | Primary Block | B1 | - +--------------------------------------+----+ - | BIB | B2 | - | OP(integrity, targets=B1, B5, B6) | | - +--------------------------------------+----+ - | BCB | B3 | - | OP(confidentiality, target=B4) | | - +--------------------------------------+----+ - | Extension Block (encrypted) | B4 | - +--------------------------------------+----+ - | Extension Block | B5 | - +--------------------------------------+----+ - | Payload Block | B6 | - +--------------------------------------+----+ - Figure 3: Security at Bundle Creation The following security actions were applied to this bundle at its time of creation. o An integrity signature applied to the canonicalized primary block (B1), the second extension block (B5) and the payload block (B6). 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 security source, security context, and security context @@ -925,43 +906,20 @@ extension block and the bundle payload. The waypoint security policy 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. The resultant bundle is illustrated in Figure 4 and the security actions are described below. Note that block IDs provided here are ordered solely for the purpose of this example and not meant to 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]. - Block in Bundle ID - +======================================+====+ - | Primary Block | B1 | - +--------------------------------------+----+ - | BIB | B2 | - | OP(integrity, targets=B1) | | - +--------------------------------------+----+ - | BIB (encrypted) | B7 | - | OP(integrity, targets=B5, B6) | | - +--------------------------------------+----+ - | BCB | B8 | - | OP(confidentiality, target=B5,B6,B7) | | - +--------------------------------------+----+ - | BCB | B3 | - | OP(confidentiality, target=B4) | | - +--------------------------------------+----+ - | Extension Block (encrypted) | B4 | - +--------------------------------------+----+ - | Extension Block (encrypted) | B5 | - +--------------------------------------+----+ - | Payload Block (encrypted) | B6 | - +--------------------------------------+----+ - Figure 4: Security At Bundle Forwarding The following security actions were applied to this bundle prior to its forwarding from the waypoint node. o Since the waypoint node wishes to encrypt blocks B5 and B6, it MUST also encrypt the BIBs providing plain-text integrity over those blocks. However, BIB B2 could not be encrypted in its entirety because it also held a signature for the primary block (B1). Therefore, a new BIB (B7) is created and security results @@ -1027,26 +985,26 @@ Security blocks must be processed in a specific order when received by a security-aware node. The processing order is as follows. o When BIBs and BCBs share a security target, BCBs MUST be evaluated first and BIBs second. 5.1.1. Receiving BCBs If a received bundle contains a BCB, the receiving node MUST - determine whether it is the security destination for any of the - security operations in the BCB. If so, the node MUST process those - operations and remove any operation-specific information from the BCB - prior to delivering data to an application at the node or forwarding - the bundle. If processing a security operation fails, the target - SHALL be processed according to the security policy. A bundle status + determine whether it is the security acceptor for any of the security + operations in the BCB. If so, the node MUST process those operations + and remove any operation-specific information from the BCB prior to + delivering data to an application at the node or forwarding the + bundle. If processing a security operation fails, the target SHALL + be processed according to the security policy. A bundle status report indicating the failure MAY be generated. When all security operations for a BCB have been removed from the BCB, the BCB MUST be removed from the bundle. 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 not the destination of the bundle, the node MUST process the BCB if directed to do so as a matter of security policy. If the security policy of a security-aware node specifies that a @@ -1072,26 +1030,26 @@ it MUST be updated to reflect the decrypted block length. If a BCB contains multiple security operations, each 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 operation for the purposes of report generation and policy processing. 5.1.2. Receiving BIBs If a received bundle contains a BIB, the receiving node MUST - determine whether it is the security destination for any of the - security operations in the BIB. If so, the node MUST process those - operations and remove any operation-specific information from the BIB - prior to delivering data to an application at the node or forwarding - the bundle. If processing a security operation fails, the target - SHALL be processed according to the security policy. A bundle status + determine whether it is the security acceptor for any of the security + operations in the BIB. If so, the node MUST process those operations + and remove any operation-specific information from the BIB prior to + delivering data to an application at the node or forwarding the + bundle. If processing a security operation fails, the target SHALL + be processed according to the security policy. A bundle status report indicating the failure MAY be generated. When all security operations for a BIB have been removed from the BIB, the BIB MUST be removed from the bundle. 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 operations mandated by this specification, when both a BIB and a BCB share a security target, it means that the security target must have been encrypted after it was integrity signed and, therefore, the BIB cannot be verified until the security target has been decrypted by @@ -1100,21 +1058,21 @@ If the security policy of a security-aware node specifies that a bundle should have applied integrity to a specific security target and no such BIB is present in the bundle, then the node MUST process this security target in accordance with the security policy. This may involve removing the security target from the bundle. If the removed security target is the payload or primary block, the bundle MAY be discarded. This action can occur at any node that has the ability to verify an integrity signature, not just the bundle destination. - If a receiving node is not the security destination of a security + If a receiving node is not the security acceptor of a security operation in a BIB it MAY attempt to verify the security operation anyway to prevent forwarding corrupt data. If the verification fails, the node SHALL process the security target in accordance to 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 the check fails at the bundle destination. If the check passes, the node MUST NOT remove the security operation from the BIB prior to forwarding. If a BIB contains multiple security operations, each operation @@ -1431,24 +1389,25 @@ of contexts can be defined with each context supporting few, if any, parameters. Security Context Examples +---------+------------+--------------------------------------------+ | Context | Parameters | Definition | | Id | | | +---------+------------+--------------------------------------------+ | 1 | Key, IV | AES-GCM-256 cipher suite with provided | - | | | ephemeral key and initialization vector. | + | | | ephemeral key and | + | | | initialization vector. | | 2 | IV | AES-GCM-256 cipher suite with | - | | | predetermined key and predetermined key | - | | | rotation policy. | + | | | predetermined key and predetermined | + | | | key rotation policy. | | 3 | Nil | AES-GCM-256 cipher suite with all info | | | | predetermined. | +---------+------------+--------------------------------------------+ Table 1 9.2. Authorship Developers or implementers should consider the diverse performance and conditions of networks on which the Bundle Protocol (and @@ -1575,20 +1534,24 @@ +-------+-----------------------------+---------------+ | Value | Description | Reference | +-------+-----------------------------+---------------+ | 11 | Block Integrity Block | This document | | 12 | Block Confidentiality Block | This document | +-------+-----------------------------+---------------+ Table 2 + The Bundle Block Types namespace notes whether a block type is meant + for use in BP version 6, BP version 7, or both. The two block types + defined in this specification are meant for use with BP version 7. + 11.2. Security Context Identifiers BPSec has a Security Context Identifier field for which IANA is requested to create and maintain a new registry named "BPSec Security Context Identifiers". Initial values for this registry are given below. The registration policy for this registry is: Specification Required. The value range is: unsigned 16-bit integer. @@ -1602,22 +1565,22 @@ +-------+-------------+---------------+ Table 3 12. References 12.1. Normative References [I-D.ietf-dtn-bpbis] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol - Version 7", draft-ietf-dtn-bpbis-14 (work in progress), - August 2019. + Version 7", draft-ietf-dtn-bpbis-18 (work in progress), + January 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . @@ -1654,26 +1617,28 @@ The following participants contributed technical material, use cases, and useful thoughts on the overall approach to this security specification: Scott Burleigh of the Jet Propulsion Laboratory, Amy Alford and Angela Hennessy of the Laboratory for Telecommunications Sciences, and Angela Dalton and Cherita Corbett of the Johns Hopkins University Applied Physics Laboratory. Authors' Addresses Edward J. Birrane, III - The Johns Hopkins University Applied Physics Laboratory + The Johns Hopkins University Applied + Physics Laboratory 11100 Johns Hopkins Rd. Laurel, MD 20723 US Phone: +1 443 778 7423 Email: Edward.Birrane@jhuapl.edu Kenneth McKeever - The Johns Hopkins University Applied Physics Laboratory + The Johns Hopkins University Applied + Physics Laboratory 11100 Johns Hopkins Rd. Laurel, MD 20723 US Phone: +1 443 778 2237 Email: Ken.McKeever@jhuapl.edu