--- 1/draft-ietf-dtn-bpsec-08.txt 2019-02-21 14:13:13.822300732 -0800 +++ 2/draft-ietf-dtn-bpsec-09.txt 2019-02-21 14:13:13.898302613 -0800 @@ -1,18 +1,18 @@ Delay-Tolerant Networking E. Birrane Internet-Draft K. McKeever Intended status: Standards Track JHU/APL -Expires: April 25, 2019 October 22, 2018 +Expires: August 25, 2019 February 21, 2019 Bundle Protocol Security Specification - draft-ietf-dtn-bpsec-08 + draft-ietf-dtn-bpsec-09 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,25 +20,25 @@ 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 April 25, 2019. + This Internet-Draft will expire on August 25, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + 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 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 @@ -48,61 +48,63 @@ 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 . . . . . . . . . . . . . . . . 7 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8 - 2.4. User-Selected Cipher Suites . . . . . . . . . . . . . . . 8 + 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 8 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 - 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10 3.4. Target Identification . . . . . . . . . . . . . . . . . . 11 3.5. Block Representation . . . . . . . . . . . . . . . . . . 11 - 3.6. Security Association Block . . . . . . . . . . . . . . . 12 - 3.7. Abstract Security Block . . . . . . . . . . . . . . . . . 14 - 3.8. Block Integrity Block . . . . . . . . . . . . . . . . . . 17 - 3.9. Block Confidentiality Block . . . . . . . . . . . . . . . 18 - 3.10. Block Interactions . . . . . . . . . . . . . . . . . . . 19 - 3.11. SA Parameters and Result Identification . . . . . . . . . 20 - 3.12. BSP Block Examples . . . . . . . . . . . . . . . . . . . 21 - 3.12.1. Example 1: Constructing a Bundle with Security . . . 21 - 3.12.2. Example 2: Adding More Security At A New Node . . . 22 - 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 24 - 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24 - 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 25 - 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 25 - 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 26 - 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 27 - 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 27 - 7. Security Policy Considerations . . . . . . . . . . . . . . . 27 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 29 - 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 30 - 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 30 - 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 31 - 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 32 - 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 32 - 9. Cipher Suite Authorship Considerations . . . . . . . . . . . 33 - 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 34 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 - 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 35 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 36 - 12.2. Informative References . . . . . . . . . . . . . . . . . 36 - Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 + 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12 + 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 14 + 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 15 + 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17 + 3.10. Parameter and Result Identification . . . . . . . . . . . 18 + 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 18 + 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 . . . . . . . . . . . . . . . . . . . . . . . 21 + 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22 + 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 22 + 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 22 + 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 23 + 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 24 + 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 24 + 7. Security Policy Considerations . . . . . . . . . . . . . . . 24 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 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 . . . . . . . . . . . . . . . . 28 + 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 29 + 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 29 + 9. Security Context Considerations . . . . . . . . . . . . . . . 30 + 9.1. Identification and Configuration . . . . . . . . . . . . 30 + 9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 31 + 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 32 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 33 + + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 33 + 12.2. Informative References . . . . . . . . . . . . . . . . . 34 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 + 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 @@ -190,22 +192,23 @@ including shared secret or private keys, is protected against access within both memory and storage devices. This specification addresses neither the fitness of externally- defined cryptographic methods nor the security of their implementation. Different networking conditions and operational considerations require varying strengths of security mechanism such that 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 - cipher suites compatible with BPSec, to include operational cipher - suites and interoperability cipher suites. + 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. 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 @@ -235,49 +238,56 @@ 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 [RFC2119]. This section defines terminology either unique to the BPSec or otherwise necessary for understanding the concepts defined in this specification. - o Bundle Source - the node which originates a bundle. The Node ID - of the BPA originating the bundle. + o Bundle Source - the node which originates a bundle. Also, the + Node ID of the BPA originating the bundle. - o Forwarder - any node that transmits a bundle in the DTN. The Node - ID of the Bundle Protocol Agent (BPA) that sent the bundle on its - most recent hop. + 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 Intermediate Receiver, Waypoint, or "Next Hop" - any node that + 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. + + o Intermediate Receiver, Waypoint, or Next Hop - any node that receives a bundle from a Forwarder that is not the Destination. - The Node ID of the BPA at any such node. + 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. + 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: integrity and confidentiality. + specification: either integrity or confidentiality. o Security Source - a bundle node that adds a security block to a - bundle. The Node ID of that node. + 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. 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 @@ -317,23 +327,21 @@ 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. 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 destination node might interpret policy - as it related to security blocks as a function of the security source - for that block. + 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 an insecure portion of the DTN, may receive the bundle and choose to apply a confidentiality service. In this case, the integrity security source is the bundle source and the confidentiality security source is the waypoint node. 2.3. Mixed Security Policy @@ -355,58 +363,53 @@ 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 its path. Some waypoints could understand security blocks but refuse to process them unless they are the bundle destination. -2.4. User-Selected Cipher Suites +2.4. User-Defined Security Contexts - The security services defined in this specification rely on a variety - of cipher suites providing integrity signatures, cipher-text, and - other information necessary to populate security blocks. Users may - select different cipher suites to implement security services. For - example, some users might prefer a SHA2 hash function for integrity - whereas other users might prefer a SHA3 hash function instead. The + A security context is the union of security algorithms (cipher + suites), policies associated with the use of those algorithms, and + configuration values. Different contexts may specify different + algorithms, different polices, or different configuration values used + in the implementation of their security services. BPSec must provide + a mechanism for users to define their own security contexts. + + For example, some users might prefer a SHA2 hash function for + integrity whereas other users might prefer a SHA3 hash function. The security services defined in this specification must provide a - mechanism for identifying what cipher suite has been used to populate - a security block. + mechanism for determining what cipher suite, policy, and + configuration has been used to populate a security block. 2.5. Deterministic Processing Whenever a node determines that it must process more than one security block in a received bundle (either because the policy at a waypoint states that it should process security blocks or because the node is the bundle destination) the order in which security blocks are processed must be deterministic. All nodes must impose this same deterministic processing order for all security blocks. This specification provides determinism in the application and evaluation of security services, even when doing so results in a loss of flexibility. 3. Security Blocks 3.1. Block Definitions - This specification defines three types of security block: the - Security Association Block (SAB), the Block Integrity Block (BIB) and - the Block Confidentiality Block (BCB). - - The SAB is used to define security associations between two - messaging endpoints. In this sense, they are similar to security - associations used in other security protocols such as IPSec, with - the exception that these associations may be pre-negotiated as a - matter of policy, parameterized as part of their definition, or - otherwise made fit for use in a challenged networking scenario. + 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 to sign the cipher-text provided by a BCB. The BCB indicates that the security target(s) have been encrypted at the BCB security source in order to protect their content while @@ -460,21 +463,21 @@ 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 association parameters and key information for the + o The security context parameters and key information 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/removed 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 @@ -504,151 +507,29 @@ in [I-D.ietf-dtn-bpbis]. That is, each security block is comprised of the following elements: o Block Type Code o Block Number o Block Processing Control Flags o CRC Type and CRC Field (if present) + o Block Data Length o Block Type Specific Data Fields Security-specific information for a security block is captured in the "Block Type Specific Data Fields". -3.6. Security Association Block - - The SAB defines a security association (SA) between bundle messaging - endpoints. This association captures the set of parameterized cipher - suite information, key information, and other annotative information - necessary to configure security services in the network. - - In deployments where data communications are challenged, the SAB - block may be omitted in favor of negotiating SAs using out-of-band - mechanisms. - - The Block Type Code of an SAB is as specified in Section 11.1. - - The Block number, Block Processing Control Flags, CRC Type and CRC - Field, and Block Data Length may be set in any way that conforms with - security policy and in compliance with [I-D.ietf-dtn-bpbis]. - - The Block Type Specific Data Fields of the SAB MUST be encoded as a - CBOR array, with each element of the array defining a unique SA. - - An individual security association (SA) MUST be encoded as a CBOR - array comprising the following fields, listed in the order in which - they must appear. - - Security Association Id: - This field identifies the identifier for the SA. This field - SHALL be represented by a CBOR unsigned integer. - - Security Association Flags: - This field identifies which optional fields are present in the - security block. This field SHALL be represented as a CBOR - unsigned integer containing a bit field of 5 bits indicating - the presence or absence of other fields, as follows. - - Bit 1 (the most-significant bit, 0x10): EID Scope Flag. - - Bit 2 (0x08): Block Type Scope Flag. - - Bit 3 (0x04): Cipher Suite Id Present Flag. - - Bit 4 (0x02): Security Source Present Flag. - - Bit 5 (the least-significant bit, 0x01): Security Association - Parameters Present Flag. - - In this field, a value of 1 indicates that the associated - security block field MUST be included in the security block. A - value of 0 indicates that the associated security block field - MUST NOT be in the security block. - - EID Scope (Optional Field): - This field identifies the message destinations (as a series of - Endpoints) for which this SA should be applied. If this field - is not present, the SA may be applied to any message endpoints - or may be filtered in some other way in accordance with - security policy. This field SHALL be represented by a CBOR - array with each element containing an EID encoded in accordance - with [I-D.ietf-dtn-bpbis] rules for representing Endpoint - Identifiers (EIDs). - - Block Type Scope (Optional Field): - This field identifies the block types for which this SA should - be applied. If this field is not present, the SA may be - applied to any block type or may be filtered in some other way - in accordance with security policy. This field SHALL be - represented by a CBOR array with each element containing a - block type encoded in accordance with [I-D.ietf-dtn-bpbis] - rules for representing block types. - - Cipher Suite Id (Optional Field): - This field identifies the cipher suite used by this SA. If - this field is not present, the cipher suite associated with - this SA MUST be known through some alternative mechanisms, such - as local security policy or out-of-band configuration. The - cipher suite Id SHALL be presented by a CBOR unsigned integer. - - Security Source (Optional Field): - This field identifies the Endpoint that inserted the security - 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 Association Parameters (Optional Field): - This field captures one or more security association 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 SA parameter. A single SA 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 SA parameter is - being specified. This field SHALL be represented as a CBOR - unsigned integer. Parameter ids are selected as described - in Section 3.11. - - * 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.11. - - The logical layout of the security association parameters array - is illustrated in Figure 1. - - +----------------+----------------+ +----------------+ - | Parameter 1 | Parameter 2 | ... | Parameter N | - +------+---------+------+---------+ +------+---------+ - | Id | Value | Id | Value | | Id | Value | - +------+---------+------+---------+ +------+---------+ - - Figure 1: Security Association Parameters - - Notes: - - o It is RECOMMENDED that security association 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. - -3.7. Abstract Security Block +3.6. Abstract Security Block The structure of the security-specific portions of a security block is identical for both the BIB and BCB Block Types. Therefore, this section defines an Abstract Security Block (ASB) data structure and discusses the definition, processing, and other constraints for using this structure. An ASB is never directly instantiated within a bundle, it is only a mechanism for discussing the common aspects of BIB and BCB security blocks. The fields of the ASB SHALL be as follows, listed in the order in @@ -659,58 +539,89 @@ This field identifies the block(s) targeted by the security operation(s) represented by this security block. Each target block is represented by its unique Block Number. This field SHALL be represented by a CBOR array of data items. Each target within this CBOR array SHALL be represented by a CBOR unsigned integer. This array MUST have at least 1 entry and each entry MUST represent the Block Number of a block that exists in the bundle. There MUST NOT be duplicate entries in this array. - Security Association Id: - This field identifies the cipher suite 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. + 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. - Security Association Flags: + 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 containing a bit field of 5 bits indicating the presence or absence of other security block fields, as follows. Bit 1 (the most-significant bit, 0x10): reserved. Bit 2 (0x08): reserved. Bit 3 (0x04): reserved. Bit 4 (0x02): Security Source Present Flag. - Bit 5 (the least-significant bit, 0x01): reserved. + Bit 5 (the least-significant bit, 0x01): Security Context + Parameters Present Flag. In this field, a value of 1 indicates that the associated security block field MUST be included in the security block. A value of 0 indicates that the associated security block field MUST NOT be in the security block. - Security Source (Optional Field): + Security Source (Optional): This field identifies the Endpoint that inserted the security 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. + + * 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. + + 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 array corresponds to the first entry in the Security Targets field of the security block, and so on. There MUST be one @@ -720,143 +631,144 @@ The set of security results for a target is also represented as a CBOR array of individual results. An individual result is represented as a 2-tuple of a result id and a result value, defined as follows. * Result Id. This field identifies which security result is being specified. Some security results capture the primary output of a cipher suite. Other security results contain additional annotative information from cipher suite processing. This field SHALL be represented as a CBOR - unsigned integer. Security result ids will be as specified - in Section 3.11. + unsigned integer. Security result Ids will be as specified + in Section 3.10. * 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.11. + 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.8. Block Integrity Block +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 Association Id MUST refer to a known SA that supports - an end-to-end authentication-cipher suite or as an end-to-end - error-detection-cipher suite. + 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.11. + key information described in Section 3.10. Notes: - o It is RECOMMENDED that SA 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 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 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 - SA. + cipher suite. - o For some SAs, (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.10. + o For some cipher suites, (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.9. Block Confidentiality Block +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 indicates to a receiving node that the payload portion of each fragment represents cipher-text. 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. - The Security Association Id MUST refer to a known SA that supports - a confidentiality cipher suite that supports authenticated - encryption with associated data (AEAD). + The Security Context Id MUST utilize a confidentiality cipher that + provides authenticated encryption with associated data (AEAD). - Additional information created by the SA (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 used. + 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 + 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 - key information described in Section 3.11. + the key 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 SA 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 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 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.10. Block Interactions +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 @@ -888,72 +800,70 @@ o A BIB integrity value MUST NOT be evaluated if the BIB is the security target of an existing BCB. In this case, the BIB data is encrypted. o A BIB integrity value MUST NOT be evaluated if the security target of the BIB is also the security target of a BCB. In such a case, the security target data contains cipher-text as it has been encrypted. - o As mentioned in Section 3.8, a BIB MUST NOT have a BCB as its + o As mentioned in Section 3.7, a BIB MUST NOT have a BCB as its 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 + suite, it is inefficient and possible 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. -3.11. SA Parameters and Result Identification +3.10. Parameter and Result Identification - SA parameters and security results each represent multiple distinct - pieces of information in a security block. Each piece of information - is assigned an identifier and a CBOR encoding. Identifiers MUST be - unique for a given SA but do not need to be unique across all SAs. - Therefore, parameter ids and security result ids are specified in the - context of an SA definition. + Security context parameters and results each represent multiple + distinct pieces of information in a security block. Each piece of + information is assigned an identifier and a CBOR encoding. + Identifiers MUST be unique for a given cipher suite but do not need + to be unique across all cipher suites. Therefore, parameter Ids and + result Ids are specified in the context of a cipher suite definition. - Individual BPSec SAs SHOULD use existing registries of identifiers - and CBOR encodings, such as those defined in [RFC8152], whenever - possible. SAs SHOULD define their own identifiers and CBOR encodings - when necessary. + Individual BPSec security context identifiers SHOULD use existing + registries of identifiers and CBOR encodings, such as those defined + in [RFC8152], whenever possible. Contexts SHOULD define their own + identifiers and CBOR encodings when necessary. - A SA can include multiple instances of the same identifier for a - parameter or result in the SAB. Parameters and results are - represented using CBOR, and any identification of a new parameter or - result must include how the value will be represented using the CBOR - specification. Ids themselves are always represented as a CBOR - unsigned integer. + Parameters and results are represented using CBOR, and any + identification of a new parameter or result must include how the + value will be represented using the CBOR specification. Ids + themselves are always represented as a CBOR unsigned integer. -3.12. BSP Block Examples +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 operations to a bundle. In the second example, a waypoint node received the bundle created in the first example and adds additional 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.12.1. Example 1: Constructing a Bundle with Security +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. Block in Bundle ID +======================================+====+ @@ -974,35 +884,35 @@ 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 and policy has them share the same cipher suite, - key, and cipher suite parameters. Had this not been the case, - multiple BIBs could have been added instead. + 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. -3.12.2. Example 2: Adding More Security At A New Node +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 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 @@ -1043,23 +953,23 @@ entirety because it also held a signature for the primary block (B1). Therefore, a new BIB (B7) is created and security results associated with B5 and B6 are moved out of BIB B2 and into BIB B7. o Now that there is no longer confusion of which plain-text integrity signatures must be encrypted, a BCB is added to the bundle with the security targets being the second extension block (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 and policy has them share the same cipher suite, key, and - cipher suite parameters. Had this not been the case, multiple - BCBs could have been added instead. + 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 generating a comparison signature. Canonicalization algorithms are used to construct a stable, end-to-end bit @@ -1083,25 +993,25 @@ Fields from plain-text to cipher-text. o Reserved flags MUST NOT be included in any canonicalization as it is not known if those flags will change in transit. These canonicalization algorithms assume that Endpoint IDs do not change from the time at which a security source adds a security block to a bundle and the time at which a node processes that security block. - Cipher suites used by SAs 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, cipher suite algorithms take precedence - over this specification. + Cipher suites 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, cipher suite algorithms take precedence over this + specification. 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. @@ -1472,21 +1383,58 @@ BPSec relies on cipher suite capabilities to prevent replay or forged message attacks. A BCB used with appropriate cryptographic mechanisms (e.g., a counter-based cipher mode) may provide replay protection under certain circumstances. Alternatively, application data itself may be augmented to include mechanisms to assert data uniqueness and then protected with a BIB, a BCB, or both along with other block data. In such a case, the receiving node would be able to validate the uniqueness of the data. -9. Cipher Suite Authorship Considerations +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. + + 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 | Key, IV | AES-GCM-256 cipher suite with provided | + | | | ephemeral key and initialization vector. | + | 2 | IV | AES-GCM-256 cipher suite with | + | | | 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 @@ -1505,60 +1453,50 @@ time may be extremely large. This may limit the utility of session key generation mechanisms, such as Diffie-Hellman, as a two-way handshake may not be feasible or reliable. o Opportunistic Access: Depending on the application environment, a given endpoint may not be guaranteed to be accessible within a certain amount of time. This may make asymmetric cryptographic architectures which rely on a key distribution center or other trust center impractical under certain conditions. - When developing new cipher suites for use with BPSec, the following - information SHOULD be considered for inclusion in these + When developing new security contexts for use with BPSec, the + following information SHOULD be considered for inclusion in these specifications. - o Cipher Suite Parameters. Cipher suites MUST define their - parameter ids, the data types of those parameters, and their CBOR + o Security Context Parameters. Security contexts MUST define their + parameter Ids, the data types of those parameters, and their CBOR encoding. - o Security Results. Cipher suites MUST define their security result - ids, the data types of those results, and their CBOR encoding. + o Security Results. Security contexts MUST define their security + result Ids, the data types of those results, and their CBOR + encoding. - o New Canonicalizations. Cipher suites may define new + o New Canonicalizations. Security contexts may define new canonicalization algorithms as necessary. - o Cipher-Text Size. Cipher suites MUST state whether they generate - cipher-text (to include any included authentication information) - that is of a different size than the input plain-text. + o Cipher-Text Size. Security contexts MUST state whether their + associated cipher suites generate cipher-text (to include any + authentication information) that is of a different size than the + input plain-text. - If a cipher suite does not wish to alter the size of the plain- - text, it should consider the following. + If a security context does not wish to alter the size of the + plain-text, it should consider defining the following policy. * Place overflow bytes, authentication signatures, and any additional authenticated data in security result fields rather than in the cipher-text itself. * Pad the cipher-text in cases where the cipher-text is smaller than the plain-text. - o If a BCB cannot alter the size of the security target then - differences in the size of the cipher-text and plain-text MUST be - handled in the following way. If the cipher-text is shorter in - length than the plain-text, padding MUST be used in accordance - with the cipher suite policy. If the cipher-text is larger than - the plain-text, overflow bytes MUST be placed in overflow - parameters in the Security Result field. Any additional - authentication information can be treated either as overflow - cipher-text or represented separately in the BCB in a security - result field, in accordance with cipher suite documentation and - security policy. - 10. Defining Other Security Blocks Other security blocks (OSBs) may be defined and used in addition to the security blocks identified in this specification. Both the usage of BIB, BCB, and any future OSBs can co-exist within a bundle and can be considered in conformance with BPSec if each of the following requirements are met by any future identified security blocks. o Other security blocks (OSBs) MUST NOT reuse any enumerations identified in this specification, to include the block type codes @@ -1597,38 +1535,37 @@ and configuration associated with blocks SHOULD be included in any OSB definition. NOTE: The burden of showing compliance with processing rules is placed upon the standards defining new security blocks and the identification of such blocks shall not, alone, require maintenance of this specification. 11. IANA Considerations - A registry of cipher suite identifiers will be required. + A registry of security context identifiers will be required. 11.1. Bundle Block Types - This specification allocates three block types from the existing + This specification allocates two block types from the existing "Bundle Block Types" registry defined in [RFC6255]. Additional Entries for the Bundle Block-Type Codes Registry: +-------+-----------------------------+---------------+ | Value | Description | Reference | +-------+-----------------------------+---------------+ - | TBD | Security Association Block | This document | | TBD | Block Integrity Block | This document | | TBD | Block Confidentiality Block | This document | +-------+-----------------------------+---------------+ - Table 1 + Table 2 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-11 (work in progress), May 2018.