--- 1/draft-ietf-dtn-bpsec-12.txt 2019-11-04 12:14:24.200478894 -0800 +++ 2/draft-ietf-dtn-bpsec-13.txt 2019-11-04 12:14:24.280480921 -0800 @@ -1,18 +1,18 @@ Delay-Tolerant Networking E. Birrane Internet-Draft K. McKeever Intended status: Standards Track JHU/APL -Expires: March 21, 2020 September 18, 2019 +Expires: May 7, 2020 November 4, 2019 Bundle Protocol Security Specification - draft-ietf-dtn-bpsec-12 + draft-ietf-dtn-bpsec-13 Abstract This document defines a security protocol providing end to end 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 March 21, 2020. + This Internet-Draft will expire on May 7, 2020. Copyright Notice Copyright (c) 2019 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 @@ -60,42 +60,42 @@ 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11 3.4. Target Identification . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . 19 + 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 . . . . . . . . . . . . . . . . . . . . . 23 + 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 . . . . . . . . . . . . . . . . . . . . . . . 32 + 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 @@ -126,25 +126,25 @@ authority). An end-to-end security service is needed that operates in all of the environments where the BP operates. 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, if any, 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. + 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. Confidentiality services ensure that target data is unintelligible to nodes in the DTN, except for authorized nodes possessing special information. This generally means producing cipher-text from plain- text and generating authentication information for that cipher-text. Confidentiality, in this context, applies to the contents of target data and does not extend to hiding the fact that confidentiality exists in the bundle. NOTE: Hop-by-hop authentication is NOT a supported security service @@ -248,38 +248,38 @@ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "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 BPA receiving the bundle. The bundle destination acts as the - security destination for every security target in every security - block in every bundle it receives. + the Bundle Protocol Agent (BPA) receiving the bundle. The bundle + destination acts as the security destination 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, - the Node ID of the Bundle Protocol Agent (BPA) that sent the - bundle on its most recent hop. + the Node ID of the BPA that sent the bundle on its most recent + hop. o Intermediate Receiver, Waypoint, or Next Hop - any node that - receives a bundle from a Forwarder that is not the Destination. - Also, the Node ID of the BPA at any such node. + 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 Block - a BPSec extension block in a bundle. o Security Context - the set of assumptions, algorithms, configurations and policies used to implement security services. @@ -293,30 +293,30 @@ 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. 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 - security-service as part of a security-operation. + security service as part of a security operation. 2. Design Decisions The application of security services in a DTN is a complex endeavor that must consider physical properties of the network, policies at - each node, and various application security requirements. This - section identifies those desirable properties that guide design - decisions for this specification and are necessary for understanding - the format and behavior of the BPSec protocol. + each node, and application security requirements. This section + identifies those desirable properties that guide design decisions for + this specification and are necessary for understanding the format and + behavior of the BPSec protocol. 2.1. Block-Level Granularity Security services within this specification must allow different blocks within a bundle to have different security services applied to them. Blocks within a bundle represent different types of information. The primary block contains identification and routing information. The payload block carries application data. Extension blocks carry a @@ -444,21 +444,21 @@ 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. 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. 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 blocks would be lost. + deterministic processing of blocks would be lost. 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 @@ -480,22 +480,22 @@ 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. o The security operations apply the same security service. For example, they are all integrity operations or all confidentiality operations. - o The security context parameters and key information for the - security operations are identical. + o The security context parameters for the security operations are + identical. o The security source for the security operations is the same. Meaning the set of operations are being added by the same node. o No security operations have the same security target, as that would violate the need for security operations to be unique. o None of the security operations conflict with security operations already present in the bundle. @@ -698,44 +698,39 @@ 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 bundle source. The security source MAY be specified as part of - key information described in Section 3.10. + security context information described in Section 3.10. Notes: - o It is RECOMMENDED that cipher suite 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 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 - cipher suite. + security context. - o For some cipher suites, (e.g., those using asymmetric keying to - produce signatures or those using symmetric keying with a group + 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. - o The use of a generally available key is RECOMMENDED if custodial - transfer is employed and all nodes SHOULD verify the bundle before - accepting custody. - 3.8. Block Confidentiality Block 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 the BCB is the Payload Block. Having that BCB in each fragment @@ -756,36 +751,35 @@ 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 bundle source. The security source MAY be specified as part of - the key information described in Section 3.10. + security context information described in Section 3.10. The BCB modifies the contents of its security target(s). When a BCB 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. Notes: - o It is RECOMMENDED that cipher suite 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 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 The BCB block processing control flags can be set independently from the processing control flags of the security target(s). The setting of such flags SHOULD be an implementation/policy decision 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 @@ -841,28 +835,28 @@ 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 - cipher suite that generates such signatures as additional security - results SHOULD be used instead. + security context that generates such signatures as additional + security results SHOULD be used instead. 3.10. Parameter and Result Identification Each security context MUST define its own context parameters and - security results. Each defined parameter and result is represented - as the tuple of an identifier and a value. Identifiers are always + 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 need to be unique amongst all security contexts. 3.11. BSP Block Examples This section provides two examples of BPSec blocks applied to a bundle. In the first example, a single node adds several security @@ -871,23 +865,25 @@ security operations. In both examples, the first column represents blocks within a bundle and the second column represents the Block Number for the block, using the terminology B1...Bn for the purpose of illustration. 3.11.1. Example 1: Constructing a Bundle with Security 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, one of the - extension blocks, and the payload. The resultant bundle is - illustrated in Figure 3 and the security actions are described below. + 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) | | @@ -909,30 +905,30 @@ 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 parameters. Had this not been the case, multiple BIBs could have been added instead. o Confidentiality for the first extension block (B4). This is accomplished by a BCB (B3). Once applied, the contents of extension block B4 are encrypted. The BCB MUST hold an authentication signature for the cipher-text either in the cipher- - text that now populated the first extension block or as a security - result in the BCB itself, depending on which cipher suite is used - to form the BCB. A plain-text integrity signature may also exist - as a security result in the BCB if one is provided by the selected - confidentiality cipher suite. + text that now populates the first extension block or as a security + result in the BCB itself, depending on which security context is + used to form the BCB. A plain-text integrity signature may also + exist as a security result in the BCB if one is provided by the + selected confidentiality security context. 3.11.2. Example 2: Adding More Security At A New Node Consider that the bundle as it is illustrated in Figure 3 is now - received by a waypoint node that wishes to encrypt the first + received by a waypoint node that wishes to encrypt the second extension block and the bundle payload. The waypoint security policy 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]. @@ -940,21 +936,21 @@ +======================================+====+ | Primary Block | B1 | +--------------------------------------+----+ | BIB | B2 | | OP(integrity, targets=B1) | | +--------------------------------------+----+ | BIB (encrypted) | B7 | | OP(integrity, targets=B5, B6) | | +--------------------------------------+----+ | BCB | B8 | - | OP(confidentiality, target=B4,B6,B7) | | + | OP(confidentiality, target=B5,B6,B7) | | +--------------------------------------+----+ | BCB | B3 | | OP(confidentiality, target=B4) | | +--------------------------------------+----+ | Extension Block (encrypted) | B4 | +--------------------------------------+----+ | Extension Block (encrypted) | B5 | +--------------------------------------+----+ | Payload Block (encrypted) | B6 | +--------------------------------------+----+ @@ -1070,22 +1066,22 @@ (see [I-D.ietf-dtn-bpbis]) MAY be generated to reflect bundle or block deletion. When a BCB is decrypted, the recovered plain-text MUST replace the cipher-text in the security target Block Type Specific Data Fields. If the Block Data Length field was modified at the time of encryption 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. + 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 @@ -1116,22 +1112,22 @@ 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 processed by the node MUST be be treated as if the security operation - has been represented by a single BIB with a single security - operation. + has been represented by a single BIB with a single security operation + for the purposes of report generation and policy processing. 5.2. Bundle Fragmentation and Reassembly If it is necessary for a node to fragment a bundle payload, and security services have been applied to that bundle, the fragmentation rules described in [I-D.ietf-dtn-bpbis] MUST be followed. As defined there and summarized here for completeness, only the payload block can be fragmented; security blocks, like all extension blocks, can never be fragmented. @@ -1417,21 +1413,22 @@ 9. Security Context Considerations 9.1. 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. + and policies, users can define multiple security contexts that use + the same cipher suite. 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 @@ -1446,29 +1443,29 @@ | | | predetermined key and predetermined key | | | | rotation policy. | | 3 | Nil | AES-GCM-256 cipher suite with all info | | | | predetermined. | +---------+------------+--------------------------------------------+ Table 1 9.2. Authorship - Cipher suite developers or implementers should consider the diverse - performance and conditions of networks on which the Bundle Protocol - (and therefore BPSec) will operate. Specifically, the delay and - capacity of delay-tolerant networks can vary substantially. Cipher - suite developers should consider these conditions to better describe - the conditions when those suites will operate or exhibit - vulnerability, and selection of these suites for implementation - should be made with consideration to the reality. There are key - differences that may limit the opportunity to leverage existing + Developers or implementers should consider the diverse performance + and conditions of networks on which the Bundle Protocol (and + therefore BPSec) will operate. Specifically, the delay and capacity + of delay-tolerant networks can vary substantially. Developers should + consider these conditions to better describe the conditions when + those contexts will operate or exhibit vulnerability, and selection + of these contexts for implementation should be made with + consideration for this reality. There are key differences that may + limit the opportunity for a security context to leverage existing cipher suites and technologies that have been developed for use in traditional, more reliable networks: o Data Lifetime: Depending on the application environment, bundles may persist on the network for extended periods of time, perhaps even years. Cryptographic algorithms should be selected to ensure protection of data against attacks for a length of time reasonable for the application. o One-Way Traffic: Depending on the application environment, it is @@ -1572,22 +1569,22 @@ 11.1. Bundle Block Types This specification allocates two block types from the existing "Bundle Block Types" registry defined in [I-D.ietf-dtn-bpbis]. Additional Entries for the Bundle Block-Type Codes Registry: +-------+-----------------------------+---------------+ | Value | Description | Reference | +-------+-----------------------------+---------------+ - | 2 | Block Integrity Block | This document | - | 3 | Block Confidentiality Block | This document | + | 11 | Block Integrity Block | This document | + | 12 | Block Confidentiality Block | This document | +-------+-----------------------------+---------------+ Table 2 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.