--- 1/draft-ietf-dtn-bpsec-22.txt 2020-10-25 19:13:13.654025791 -0700 +++ 2/draft-ietf-dtn-bpsec-23.txt 2020-10-25 19:13:13.742028006 -0700 @@ -1,18 +1,18 @@ Delay-Tolerant Networking E. Birrane Internet-Draft K. McKeever Intended status: Standards Track JHU/APL -Expires: September 9, 2020 March 8, 2020 +Expires: April 28, 2021 October 25, 2020 Bundle Protocol Security Specification - draft-ietf-dtn-bpsec-22 + draft-ietf-dtn-bpsec-23 Abstract This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -20,21 +20,21 @@ 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 September 9, 2020. + This Internet-Draft will expire on April 28, 2021. Copyright Notice 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 @@ -49,63 +49,65 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Supported Security Services . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 9 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9 - 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 10 + 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 10 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11 3.4. Target Identification . . . . . . . . . . . . . . . . . . 12 3.5. Block Representation . . . . . . . . . . . . . . . . . . 13 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 13 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 16 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 17 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 18 3.10. Parameter and Result Identification . . . . . . . . . . . 19 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 20 3.11.1. Example 1: Constructing a Bundle with Security . . . 20 3.11.2. Example 2: Adding More Security At A New Node . . . 21 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 23 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 24 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 24 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 25 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 26 - 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 26 - 7. Security Policy Considerations . . . . . . . . . . . . . . . 26 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 28 - 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 29 - 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 29 - 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 30 - 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 31 - 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 32 - 9. Security Context Considerations . . . . . . . . . . . . . . . 32 - 9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 32 - 9.2. Identification and Configuration . . . . . . . . . . . . 33 - 9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 34 - 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 35 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 37 - 11.2. Security Context Identifiers . . . . . . . . . . . . . . 37 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 12.2. Informative References . . . . . . . . . . . . . . . . . 38 - Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 39 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 + 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 27 + 7. Security Policy Considerations . . . . . . . . . . . . . . . 27 + 7.1. Security Reason Codes . . . . . . . . . . . . . . . . . . 28 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 30 + 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 31 + 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 31 + 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 32 + 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 33 + 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 33 + 9. Security Context Considerations . . . . . . . . . . . . . . . 34 + 9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 34 + 9.2. Identification and Configuration . . . . . . . . . . . . 35 + 9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 36 + 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 37 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 + 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 39 + 11.2. Bundle Status Report Reason Codes . . . . . . . . . . . 39 + 11.3. Security Context Identifiers . . . . . . . . . . . . . . 40 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 40 + 12.2. Informative References . . . . . . . . . . . . . . . . . 41 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 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 security services between a security source and a security acceptor. When the security source is the bundle source and when the security acceptor is the bundle destination, the security service provides end-to-end protection. @@ -153,65 +155,57 @@ NOTE: Hop-by-hop authentication is NOT a supported security service in this specification, for two reasons. 1. The term "hop-by-hop" is ambiguous in a BP overlay, as nodes that are adjacent in the overlay may not be adjacent in physical connectivity. This condition is difficult or impossible to detect and therefore hop-by-hop authentication is difficult or impossible to enforce. - 2. Networks in which BPSec may be deployed may have a mixture of - security-aware and not-security-aware nodes. Hop-by-hop - authentication cannot be deployed in a network if adjacent nodes - in the network have different security capabilities. + 2. Hop-by-hop authentication cannot be deployed in a network if + adjacent nodes in the network have incompatible security + capabilities. 1.2. Specification Scope This document defines the security services provided by the BPSec. This includes the data specification for representing these services as BP extension blocks, and the rules for adding, removing, and processing these blocks at various points during the bundle's traversal of the DTN. - BPSec applies only to those nodes that implement it, known as - "security-aware" nodes. There might be other nodes in the DTN that - do not implement BPSec. While all nodes in a BP overlay can exchange - bundles, BPSec security operations can only happen at BPSec security- - aware nodes. - BPSec addresses only the security of data traveling over the DTN, not the underlying DTN itself. Furthermore, while the BPSec protocol can provide security-at-rest in a store-carry-forward network, it does not address threats which share computing resources with the DTN and/ or BPSec software implementations. These threats may be malicious software or compromised libraries which intend to intercept data or recover cryptographic material. Here, it is the responsibility of the BPSec implementer to ensure that any cryptographic material, including shared secret or private keys, is protected against access within both memory and storage devices. + Completely trusted networks are extremely uncommon. Amongst + untrusted networks, different networking conditions and operational + considerations require varying strengths of security mechanism. + Mandating a single security context may result in too much security + for some networks and too little security in others. It is expected + that separate documents define different security contexts for use in + different networks. A set of default security contexts are defined + in ([I-D.ietf-dtn-bpsec-interop-sc]) and provide basic security + services for interoperability testing and for operational use on the + terrestrial Internet. + This specification addresses neither the fitness of externally- defined cryptographic methods nor the security of their - implementation. Completely trusted networks are extremely uncommon. - Amongst untrusted networks, different networking conditions and - operational considerations require varying strengths of security - mechanism. Mandating a cipher suite in this specification may result - in too much security for some networks and too little security in - others. It is expected that separate documents will be standardized - to define security contexts and cipher suites compatible with BPSec, - to include those that should be used to assess interoperability and - those fit for operational use in various network scenarios. An - example security context has been defined - ([I-D.ietf-dtn-bpsec-interop-sc]) to support interoperability testing - and illustrate how security contexts should be defined for this - specification. + implementation. This specification does not address the implementation of security policy and does not provide a security policy for the BPSec. Similar to cipher suites, security policies are based on the nature and capabilities of individual networks and network operational concepts. This specification does provide policy considerations when building a security policy. With the exception of the Bundle Protocol, this specification does not address how to combine the BPSec security blocks with other @@ -242,21 +236,21 @@ Security Protocol [I-D.birrane-dtn-sbsp] documents introduced the concepts of using BP extension blocks for security services in a DTN. The BPSec is a continuation and refinement of these documents. 1.4. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. . + capitals, as shown here. 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 acceptor for every security target in every security block in every bundle it receives. @@ -283,26 +277,27 @@ 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 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 Operation - the application of a given 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 + given 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 - a process that gives some protection to a security target. For example, this specification defines security services for plain text integrity, plain text confidentiality, and cipher text integrity. o Security Source - a bundle node that adds a security block to a bundle. Also, the Node ID of that node. o Security Target - the block within a bundle that receives a @@ -344,22 +339,22 @@ A bundle can have multiple security blocks and these blocks can have different security sources. BPSec implementations MUST NOT assume that all blocks in a bundle have the same security operations applied to them. The Bundle Protocol allows extension blocks to be added to a bundle at any time during its existence in the DTN. When a waypoint adds a new extension block to a bundle, that extension block MAY have security services applied to it by that waypoint. Similarly, a - waypoint MAY add a security service to an existing extension block, - consistent with its security policy. + waypoint MAY add a security service to an existing block, consistent + with its security policy. When a waypoint adds a security service to the bundle, the waypoint is the security source for that service. The security block(s) which represent that service in the bundle may need to record this security source as the bundle destination might need this information for processing. For example, a bundle source may choose to apply an integrity service to its plain text payload. Later a waypoint node, representing a gateway to another portion of the DTN, may receive the bundle and @@ -375,25 +370,20 @@ to ensure that a bundle be delivered to a security acceptor prior to being delivered to the bundle destination. Generally, if a bundle reaches a waypoint that has the appropriate configuration and policy to act as a security acceptor for a security service in the bundle, then the waypoint should act as that security acceptor. 2.3. Mixed Security Policy 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 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 @@ -438,86 +428,96 @@ 3. Security Blocks 3.1. Block Definitions This specification defines two types of security block: the Block Integrity Block (BIB) and the Block Confidentiality Block (BCB). The BIB is used to ensure the integrity of its plain text security target(s). The integrity information in the BIB MAY be verified by any node along the bundle path from the BIB security source to - the bundle destination. Security-aware waypoints add or remove - BIBs from bundles in accordance with their security policy. BIBs - are never used for integrity protection of the cipher text - provided by a BCB. + the bundle destination. Waypoints add or remove BIBs from bundles + in accordance with their security policy. BIBs are never used for + integrity protection of the cipher text provided by a BCB. + Because security policy at BPSec nodes may differ regarding + integrity verification, BIBs do not guarantee hop-by-hop + authentication, as discussed in Section 1.1. The BCB indicates that the security target(s) have been encrypted at the BCB security source in order to protect their content while - in transit. The BCB is decrypted by security-aware nodes in the - network, up to and including the bundle destination, as a matter - of security policy. BCBs additionally provide integrity + in transit. The BCB is decrypted by security acceptor nodes in + the network, up to and including the bundle destination, as a + matter of security policy. BCBs additionally provide integrity protection mechanisms for the cipher text they generate. 3.2. Uniqueness Security operations in a bundle MUST be unique; the same security service MUST NOT be applied to a security target more than once in a - bundle. Since a security operation is represented as a security - block, this limits what security blocks may be added to a bundle: if - adding a security block to a bundle would cause some other security - block to no longer represent a unique security operation then the new - block MUST NOT be added. - - The uniqueness requirement imposed by this specification implies that - the security source for some security target is providing the initial - service for that target. This is the case when the security source - is also the source of the target. This can also occur when the - security source is adding the service to a pre-existing target for - the first time. If more complex security combinations are required, - this specification allows for the definition of custom security - contexts (Section 9) and other security blocks (Section 10). - - A security operation may be removed from a bundle as part of - processing a security block and, once removed, the same security - operation may be re-applied by adding a new security block into the - bundle. In this case, conflicting security blocks never co-exist in - the bundle at the same time. - - It is important to note that any cipher text integrity mechanism - supplied by the BCB is considered part of the confidentiality service - and, therefore, unique from the plain text integrity service provided - by the BIB. + bundle. Since a security operation is represented by a security + block, this means that multiple security blocks of the same type + cannot share the same security targets. A new security block MUST + NOT be added to a bundle if a pre-existing security block of the same + type is already defined for the security target of the new security + block. - If multiple security blocks representing the same security operation - were allowed in a bundle at the same time, there would exist - ambiguity regarding block processing order and the property of - deterministic processing of blocks would be lost. + This uniqueness requirement ensures that there is no ambiguity + related to the order in which security blocks are processed or how + security policy can be specified to require certain security services + be present in a bundle. Using the notation OP(service, target), several examples illustrate this uniqueness requirement. o Signing the payload twice: The two operations OP(integrity, payload) and OP(integrity, payload) are redundant and MUST NOT both be present in the same bundle at the same time. o Signing different blocks: The two operations OP(integrity, payload) and OP(integrity, extension_block_1) are not redundant and both may be present in the same bundle at the same time. Similarly, the two operations OP(integrity, extension_block_1) and OP(integrity,extension_block_2) are also not redundant and may both be present in the bundle at the same time. o Different Services on same block: The two operations OP(integrity, payload) and OP(confidentiality, payload) are not inherently redundant and may both be present in the bundle at the same time, pursuant to other processing rules in this specification. + NOTES: + + A security block may be removed from a bundle as part of security + processing at a waypoint node with a new security block being + added to the bundle by that node. In this case, conflicting + security blocks never co-exist in the bundle at the same time and + the uniqueness requirement is not violated. + + A cipher text integrity mechanism (such as associated + authenticated data) calculated by a cipher suite and transported + in a BCB is considered part of the confidentiality service and, + therefore, unique from the plain text integrity service provided + by a BIB. + + The security blocks defined in this specification (BIB and BCB) + are designed with the intention that the BPA adding these blocks + is the authoritative source of the security service. If a BPA + adds a BIB on a security target, then the BIB is expected to be + the authoritative source of integrity for that security target. + If a BPA adds a BCB to a security target, then the BCB is expected + to be the authoritative source of confidentiality for that + security target. More complex scenarios, such as having multiple + nodes in a network sign the same security target, can be + accommodated using the definition of custom security contexts + (Section 9) and/or the definition of other security blocks + (Section 10). + 3.3. Target Multiplicity A single security block MAY represent multiple security operations as a way of reducing the overall number of security blocks present in a bundle. In these circumstances, reducing the number of security blocks in the bundle reduces the amount of redundant information in the bundle. A set of security operations can be represented by a single security block when all of the following conditions are true. @@ -610,21 +610,21 @@ this array. The order of elements in this list has no semantic meaning outside of the context of this block. Within the block, the ordering of targets must match the ordering of results associated with these targets. Security Context Id: This field identifies the security context used to implement the security service represented by this block and applied to each security target. This field SHALL be represented by a CBOR unsigned integer. The values for this Id should come from - the registry defined in Section 11.2 + the registry defined in Section 11.3 Security Context Flags: This field identifies which optional fields are present in the security block. This field SHALL be represented as a CBOR unsigned integer whose contents shall be interpreted as a bit field. Each bit in this bit field indicates the presence (bit set to 1) or absence (bit set to 0) of optional data in the security block. The association of bits to security block data is defined as follows. @@ -647,26 +647,26 @@ block in the bundle. If the security source field is not present then the source MUST be inferred from other information, such as the bundle source, previous hop, or other values defined by security policy. This field SHALL be represented by a CBOR array in accordance with [I-D.ietf-dtn-bpbis] rules for representing Endpoint Identifiers (EIDs). Security Context Parameters (Optional): This field captures one or more security context parameters - that should be provided to security-aware nodes when processing - the security service described by this security block. This - field SHALL be represented by a CBOR array. Each entry in this - array is a single security context parameter. A single - parameter SHALL also be represented as a CBOR array comprising - a 2-tuple of the id and value of the parameter, as follows. + that should be used when processing the security service + described by this security block. This field SHALL be + represented by a CBOR array. Each entry in this array is a + single security context parameter. A single parameter SHALL + also be represented as a CBOR array comprising a 2-tuple of the + id and value of the parameter, as follows. * Parameter Id. This field identifies which parameter is being specified. This field SHALL be represented as a CBOR unsigned integer. Parameter Ids are selected as described in Section 3.10. * Parameter Value. This field captures the value associated with this parameter. This field SHALL be represented by the applicable CBOR representation of the parameter, in accordance with Section 3.10. @@ -745,28 +745,37 @@ an error detection mechanism. 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 parameters 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 Designers SHOULD 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. + integrity mechanisms for the same target define a multi-result + security context. Such a context could generate multiple security + results for the same security target using different integrity- + protection mechanisms or different configurations for the same + integrity-protection mechanism. + + o A BIB is used to verify the plain text integrity of its security + target. However, a single BIB MAY include security results for + blocks other than its security target when doing so establishes a + needed relationship between the BIB security target and other + blocks in the bundle (such as the primary block). o Security information MAY be checked at any hop on the 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. @@ -781,24 +790,26 @@ it can't be processed" flag set. Removing a BCB from a bundle without decrypting its security targets removes information from the bundle necessary for their later decryption. The block-type-specific-data fields follow the structure of the ASB. A security target listed in the Security Targets field can reference the payload block, a non-security extension block, or a BIB. A BCB MUST NOT include another BCB as a security target. A - BCB MUST NOT target the primary block. + BCB MUST NOT target the primary block. A BCB MUST NOT target a + BIB block unless it shares a security target with that BIB block. - The Security Context MUST utilize a confidentiality cipher that - provides authenticated encryption with associated data (AEAD). + Any Security Context used by a BCB MUST utilize a confidentiality + cipher that provides authenticated encryption with associated data + (AEAD). Additional information created by a cipher suite (such as an authentication tag) can be placed either in a security result field or in the generated cipher text. The determination of where to place this information is a function of the cipher suite and security context used. 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 @@ -822,24 +833,24 @@ for the encrypting node. 3.9. Block Interactions The security block types defined in this specification are designed to be as independent as possible. However, there are some cases where security blocks may share a security target creating processing dependencies. If a security target of a BCB is also a security target of a BIB, an - undesirable condition occurs where a security aware waypoint would be - unable to validate the BIB because one of its security target's - contents have been encrypted by a BCB. To address this situation the - following processing rules MUST be followed. + undesirable condition occurs where a waypoint would be unable to + validate the BIB because one of its security target's contents have + been encrypted by a BCB. To address this situation the following + processing rules MUST be followed. o When adding a BCB to a bundle, if some (or all) of the security targets of the BCB also match all of the security targets of an existing BIB, then the existing BIB MUST also be encrypted. This can be accomplished by either adding a new BCB that targets the existing BIB, or by adding the BIB to the list of security targets for the BCB. Deciding which way to represent this situation is a matter of security policy. o When adding a BCB to a bundle, if some (or all) of the security @@ -872,23 +883,24 @@ 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. 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 of adding both a BIB and then a - BCB for the security target at the security source. + security context that generates an integrity-protection mechanism as + one or more additional security results MUST be used instead of + adding both a BIB and then a BCB for the security target at the + security source. 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 @@ -1017,74 +1029,87 @@ (B5) and the payload (B6) as well as the newly created BIB holding their plain text integrity signatures (B7). A single new BCB is used in this case because all three targets share a security source, security context, and security context parameters. Had this not been the case, multiple BCBs could have been added instead. 4. Canonical Forms Security services require consistency and determinism in how - information is presented to cipher suites at the security source and - at a receiving node. For example, integrity services require that - the same target information (e.g., the same bits in the same order) - is provided to the cipher suite when generating an original signature - and when validating a signature. Canonicalization algorithms are - used to construct a stable, end-to-end bit representation of a target - block. + information is presented to cipher suites at security sources, + verifiers, and acceptors. For example, integrity services require + that the same target information (e.g., the same bits in the same + order) is provided to the cipher suite when generating an original + signature and when validating a signature. Canonicalization + algorithms transcode the contents of a security target into a + canonical form. Canonical forms are used to generate input to a security context for - security processing at a security-aware node. + security processing at a BP node. If the values of a security target + are unchanged, then the canonical form of that target will be the + same even if the encoding of those values for wire transmission is + different. BPSec operates on data fields within bundle blocks (e.g., the block- type-specific-data field). In their canonical form, these fields MUST include their own CBOR encoding and MUST NOT include any other encapsulating CBOR encoding. For example, the canonical form of the block-type-specific-data field is a CBOR byte string existing within the CBOR array containing the fields of the extension block. The entire CBOR byte string is considered the canonical block-type- specific-data field. The CBOR array framing is not considered part of the field. - The canonical form of the primary block is specified in - [I-D.ietf-dtn-bpbis]. + The canonical form of the primary block is as specified in + [I-D.ietf-dtn-bpbis] with the following constraint. + + o CBOR values from the primary block MUST be canonicalized using the + rules for Canonical CBOR, as specified in [RFC7049]. Canonical + CBOR generally requires that integers and type lengths are encoded + to be as small as possible, that map values be sorted, and that + indefinite-length items be made into definite-length items. All non-primary blocks share the same block structure and are canonicalized as specified in [I-D.ietf-dtn-bpbis] with the following - exceptions. + constraints. - o If the service being applied is a confidentiality service, then - the block type code, block number, block processing control flags, - CRC type and CRC field (if present), and the length indication of - the block-type-specific-data field MUST NOT be included in a - canonical form. Confidentiality services are used solely to - convert block data in the block-type-specific-data field from - plain text to cipher text. + o CBOR values from the non-primary block MUST be canonicalized using + the rules for Canonical CBOR, as specified in [RFC7049]. - o Reserved flags in the block processing control flags field MUST be - set to 0 in a canonical form as it is not known if those flags - will change in transit. + o Only the block-type-specific-data field may be provided to a + cipher suite for encryption as part of a confidentiality security + service. Other fields within a non-primary-block MUST NOT be + encrypted or decrypted and MUST NOT be included in the canonical + form used by the cipher suite for encryption and decryption. + These other fields MAY have an integrity protection mechanism + applied to them by treating them as associated authenticated data. - Cipher suites and security contexts MAY define their own - canonicalization algorithms and require the use of those algorithms - over the ones provided in this specification. In the event of - conflicting canonicalization algorithms, those algorithms take - precedence over this specification. + o Reserved and unassigned flags in the block processing control + flags field MUST be set to 0 in a canonical form as it is not + known if those flags will change in transit. + + Security contexts MAY define their own canonicalization algorithms + and require the use of those algorithms over the ones provided in + this specification. In the event of conflicting canonicalization + algorithms, algorithms defined in a security context take precedence + over this specification when constructing canonical forms for that + security context. 5. Security Processing This section describes the security aspects of bundle processing. 5.1. Bundles Received from Other Nodes Security blocks must be processed in a specific order when received - by a security-aware node. The processing order is as follows. + by a BP 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 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 @@ -1093,27 +1118,28 @@ 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 node - should have applied confidentiality to a specific security target and - no such BCB is present in the bundle, then the node MUST process this - security target in accordance with the security policy. It is - recommended that the node remove the security target from the bundle. - If the removed security target is the payload block, the bundle MUST - be discarded. + If the security policy of a node specifies that a node should have + applied confidentiality to a specific security target and no such BCB + is present in the bundle, then the node MUST process this security + target in accordance with the security policy. It is RECOMMENDED + that the node remove the security target from the bundle because the + confidentiality (and possibly the integrity) of the security target + cannot be guaranteed. If the removed security target is the payload + block, the bundle MUST be discarded. If an encrypted payload block cannot be decrypted (i.e., the cipher text cannot be authenticated), then the bundle MUST be discarded and processed no further. If an encrypted security target other than the payload block cannot be decrypted then the associated security target and all security blocks associated with that target MUST be discarded and processed no further. In both cases, requested status reports (see [I-D.ietf-dtn-bpbis]) MAY be generated to reflect bundle or block deletion. @@ -1144,29 +1170,29 @@ 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 processing the BCB. - If the security policy of a security-aware node specifies that a node - 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. It is - RECOMMENDED that the node remove the security target from the bundle - if the security target is not the payload or primary block. If the - 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 the security policy of a node specifies that a node 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. It is RECOMMENDED + that the node remove the security target from the bundle if the + security target is not the payload or primary block. If the 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 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. @@ -1227,62 +1253,119 @@ of the bundle, the destination of the bundle, or some other information related to the bundle. o If a waypoint has been configured to add a security operation to a bundle, and the received bundle already has the security operation applied, then the receiver must understand what to do. The receiver may discard the bundle, discard the security target and associated BPSec blocks, replace the security operation, or some other action. - o It is recommended that security operations be considered for every + o It is RECOMMENDED that security operations be applied to every block in a bundle and that the default behavior of a bundle agent is to use the security services defined in this specification. Designers should only deviate from the use of security operations when the deviation can be justified - such as when doing so causes downstream errors when processing blocks whose contents must be inspected or changed at one or more hops along the path. - o It is recommended that BCBs be allowed to alter the size of - extension blocks and the payload block. However, care must be - taken to ensure that changing the size of the payload block while - the bundle is in transit do not negatively affect bundle - processing (e.g., calculating storage needs, scheduling - transmission times). + o BCB security contexts can alter the size of extension blocks and + the payload block. Security policy SHOULD consider how changes to + the size of a block could negatively effect bundle processing + (e.g., calculating storage needs and scheduling transmission + times). o Adding a BIB to a security target that has already been encrypted by a BCB is not allowed. If this condition is likely to be encountered, there are (at least) three possible policies that could handle this situation. 1. At the time of encryption, a security context can be selected - which computes a plain text integrity signature and included - as a security context result field. + which computes a plain text integrity-protection mechanism + that is included as a security context result field. 2. The encrypted block may be replicated as a new block with a new block number and given integrity protection. 3. An encapsulation scheme may be applied to encapsulate the security target (or the entire bundle) such that the encapsulating structure is, itself, no longer the security target of a BCB and may therefore be the security target of a BIB. - o It is recommended that security policy address whether cipher - suites whose cipher text is larger than the initial plain text are - permitted and, if so, for what types of blocks. Changing the size - of a block may cause processing difficulties for networks that - calculate block offsets into bundles or predict transmission times - or storage availability as a function of bundle size. In other - cases, changing the size of a payload as part of encryption has no + o Security policy SHOULD address whether cipher suites whose cipher + text is larger than the initial plain text are permitted and, if + so, for what types of blocks. Changing the size of a block may + cause processing difficulties for networks that calculate block + offsets into bundles or predict transmission times or storage + availability as a function of bundle size. In other cases, + changing the size of a payload as part of encryption has no significant impact. +7.1. Security Reason Codes + + Bundle protocol agents (BPAs) must process blocks and bundles in + accordance with both BP policy and BPSec policy. The decision to + receive, forward, deliver, or delete a bundle may be communicated to + the report-to address of the bundle, in the form of a status report, + as a method of tracking the progress of the bundle through the + network. The status report for a bundle may be augmented with a + "reason code" explaining why the particular action was taken on the + bundle. + + This section describes a set of reason codes associated with the + security processing of a bundle. Security reason codes are assigned + in accordance with Section 11.2. + + Missing Security Operation: + This reason code indicates that a bundle was missing one or + more required security operations. This reason code is + typically used by a security verifier or security acceptor. + + Unknown Security Operation: + This reason code indicates that one or more security operations + present in a bundle cannot be understood by the security + verifier or security acceptor for the operation. For example, + this reason code may be used if a security block references an + unknown security context identifier or security context + parameter. This reason code should not be used for security + operations for which the node is not a security verifier or + security acceptor; there is no requirement that all nodes in a + network understand all security contexts, security context + parameters, and security services for every bundle in a + network. + + Unexpected Security Operation: + This reason code indicates that a receiving node is neither a + security verifier nor a security acceptor for at least one + security operation in a bundle. This reason code should not be + seen as an error condition; not every node is a security + verifier or security acceptor for every security operation in + every bundle. In certain networks, this reason code may be + useful in identifying misconfigurations of security policy. + + Failed Security Operation: + This reason code indicates that one or more security operations + in a bundle failed to process as expected for reasons other + than misconfiguration. This may occur when a security-source + is unable to add a security block to a bundle. This may occur + if the target of a security operation fails to verify using the + defined security context at a security verifier. This may also + occur if a security operation fails to be processed without + error at a security acceptor. + + Conflicting Security Operations: + This reason code indicates that two or more security operations + in a bundle are not conformant with the BPSec specification and + that security processing was unable to proceed because of a + BPSec protocol violation. + 8. Security Considerations Given the nature of DTN applications, it is expected that bundles may traverse a variety of environments and devices which each pose unique security risks and requirements on the implementation of security within BPSec. For these reasons, it is important to introduce key threat models and describe the roles and responsibilities of the BPSec protocol in protecting the confidentiality and integrity of the data against those threats. This section provides additional discussion on security threats that BPSec will face and describes how @@ -1297,25 +1380,23 @@ portions of the DTN) are completely under the control of an attacker. 8.1. Attacker Capabilities and Objectives BPSec was designed to protect against MITM threats which may have access to a bundle during transit from its source, Alice, to its destination, Bob. A MITM node, Mallory, is a non-cooperative node operating on the DTN between Alice and Bob that has the ability to receive bundles, examine bundles, modify bundles, forward bundles, and generate bundles at will in order to compromise the - confidentiality or integrity of data within the DTN. For the - purposes of this section, any MITM node is assumed to effectively be - security-aware even if it does not implement the BPSec protocol. - There are three classes of MITM nodes which are differentiated based - on their access to cryptographic material: + confidentiality or integrity of data within the DTN. There are three + classes of MITM nodes which are differentiated based on their access + to cryptographic material: o Unprivileged Node: Mallory has not been provisioned within the secure environment and only has access to cryptographic material which has been publicly-shared. o Legitimate Node: Mallory is within the secure environment and therefore has access to cryptographic material which has been provisioned to Mallory (i.e., K_M) as well as material which has been publicly-shared. @@ -1502,71 +1583,94 @@ inappropriate for use in a well-resourced, well connected node. This does not mean that the use of BPSec in a particular network is meant to be used without security contexts for interoperability and default behavior. Network designers must identify the minimal set of security contexts necessary for functions in their network. For example, a default set of security contexts could be created for use over the terrestrial Internet and required by any BPSec implementation communicating over the terrestrial Internet. - Implementations of BPSec MUST support the mandated security contexts - of the networks in which they are applied. If no set of security - contexts is mandated for a given network, then the BPSec - implementation MUST, at a minimum, implement the security context - defined in [I-D.ietf-dtn-bpsec-interop-sc]. If a node serves as a - gateway amongst two or more networks, the BPSec implementation at - that node MUST support the union of security contexts mandated in - those networks. + To ensure interoperability among various implementations, all BPSec + implementations MUST support at least the current IETF standards- + track mandatory security context(s). As of this writing, that BCP + mandatory security context is specified in + [I-D.ietf-dtn-bpsec-interop-sc], but the mandatory security + context(s) might change over time in accordance with usual IETF + processes. Such changes are likely to occur in the future if/when + flaws are discovered in the applicable cryptographic algorithms, for + example. + + Additionally, BPsec implementations need to support the security + contexts which are specified and/or used by the BP networks in which + they are deployed. + + If a node serves as a gateway amongst two or more networks, the BPSec + implementation at that node needs to support the union of security + contexts mandated in those networks. BPSec has been designed to allow for a diversity of security contexts and for new contexts to be defined over time. The use of different security contexts does not change the BPSec protocol itself and the definition of new security contexts MUST adhere to the requirements of such contexts as presented in this section and generally in this specification. Implementors should monitor the state of security context specifications to check for future updates and replacement. 9.2. Identification and Configuration - Security blocks must uniquely define the security context for their - services. This context MUST be uniquely identifiable and MAY use - parameters for customization. Where policy and configuration - decisions can be captured as parameters, the security context - identifier may identify a cipher suite. In cases where the same - cipher suites are used with differing predetermined configurations - and policies, users can define multiple security contexts that use - the same cipher suite. + Security blocks uniquely identify the security context to be used in + the processing of their security services. The security context for + a security block MUST be uniquely identifiable and MAY use parameters + for customization. + + To reduce the number of security contexts used in a network, security + context designers should make security contexts customizable through + the definition of security context parameters. For example, a single + security context could be associated with a single cipher suite and + security context parameters could be used to configure the use of + this security context with different key lengths and different key + management options without needing to define separate security + contexts for each possible option. + + A single security context may be used in the application of more than + one security service. This means that a security context identifier + MAY be used with a BIB, with a BCB, or with any other BPSec-compliant + security block. The definition of a security context MUST identify + which security services may be used with the security context, how + security context parameters are interpreted as a function of the + security operation being supported, and which security results are + produced for each security service. Network operators must determine the number, type, and configuration of security contexts in a system. Networks with rapidly changing configurations may define relatively few security contexts with each context customized with multiple parameters. For networks with more stability, or an increased need for confidentiality, a larger number of contexts can be defined with each context supporting few, if any, parameters. Security Context Examples +---------+------------+--------------------------------------------+ | Context | Parameters | Definition | | Id | | | +---------+------------+--------------------------------------------+ | 1 | Encrypted | AES-GCM-256 cipher suite with provided | | | Key, IV | ephemeral key encrypted with a | | | | predetermined key encryption key and clear | | | | text 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.3. Authorship Developers or implementers should consider the diverse performance and conditions of networks on which the Bundle Protocol (and @@ -1703,49 +1807,78 @@ | TBA | Block Integrity Block | This document | | TBA | 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 +11.2. Bundle Status Report Reason Codes + + This specification allocates five reason codes from the existing + "Bundle Status Report Reason Codes" registry defined in [RFC6255]. + + Additional Entries for the Bundle Status Report Reason Codes + Registry: + + +---------+-------+-----------------------+-------------------------+ + | BP | Value | Description | Reference | + | Version | | | | + +---------+-------+-----------------------+-------------------------+ + | 7 | TBD | Missing Security | This document, Section | + | | | Operation | Section 7.1 | + | 7 | TBD | Unknown Security | This document, Section | + | | | Operation | Section 7.1 | + | 7 | TBD | Unexpected Security | This document, Section | + | | | Operation | Section 7.1 | + | 7 | TBD | Failed Security | This document, Section | + | | | Operation | Section 7.1 | + | 7 | TBD | Conflicting Security | This document, Section | + | | | Operation | Section 7.1 | + +---------+-------+-----------------------+-------------------------+ + +11.3. 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. BPSec Security Context Identifier Registry +-------+-------------+---------------+ | Value | Description | Reference | +-------+-------------+---------------+ + | < 0 | Reserved | This document | | 0 | Reserved | This document | +-------+-------------+---------------+ Table 3 + Negative security context identifiers are reserved for local/site- + specific uses. The use of 0 as a security context identifier is for + non-operational testing purposes only. + 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-22 (work in progress), - February 2020. + Version 7", draft-ietf-dtn-bpbis-26 (work in progress), + July 2020. [I-D.ietf-dtn-bpsec-interop-sc] Birrane, E., "BPSec Interoperability Security Contexts", draft-ietf-dtn-bpsec-interop-sc-01 (work in progress), February 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -1790,26 +1923,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, Angela Hennessy of the Laboratory for Telecommunications Sciences, and Amy Alford, 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