--- 1/draft-ietf-dtn-bpsec-07.txt 2018-10-22 09:13:16.304750819 -0700 +++ 2/draft-ietf-dtn-bpsec-08.txt 2018-10-22 09:13:16.380752619 -0700 @@ -1,18 +1,18 @@ Delay-Tolerant Networking E. Birrane Internet-Draft K. McKeever Intended status: Standards Track JHU/APL -Expires: January 2, 2019 July 1, 2018 +Expires: April 25, 2019 October 22, 2018 Bundle Protocol Security Specification - draft-ietf-dtn-bpsec-07 + draft-ietf-dtn-bpsec-08 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 January 2, 2019. + This Internet-Draft will expire on April 25, 2019. Copyright Notice Copyright (c) 2018 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 @@ -43,65 +43,66 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Supported Security Services . . . . . . . . . . . . . . . 3 1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4 1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5 - 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 6 + 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.5. Deterministic Processing . . . . . . . . . . . . . . . . 8 + 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 - 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10 3.4. Target Identification . . . . . . . . . . . . . . . . . . 11 3.5. Block Representation . . . . . . . . . . . . . . . . . . 11 - 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 11 - 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 14 - 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 15 - 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 16 - 3.10. Cipher Suite Parameter and Result Identification . . . . 18 - 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 18 - 3.11.1. Example 1: Constructing a Bundle with Security . . . 18 - 3.11.2. Example 2: Adding More Security At A New Node . . . 19 - 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. Cipher Suite Authorship Considerations . . . . . . . . . . . 30 - 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 31 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 - 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 32 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 33 - 12.2. Informative References . . . . . . . . . . . . . . . . . 33 - Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 + 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 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 @@ -382,22 +383,30 @@ 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 two types of security block: the Block - Integrity Block (BIB) and the Block Confidentiality Block (BCB). + 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. 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 @@ -431,43 +440,42 @@ 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. + 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. 3.3. Target Multiplicity Under special circumstances, 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. o The security operations apply the same security service. For example, they are all integrity operations or all confidentiality operations. - o The cipher suite parameters and key information for the security - operations are identical. + o The security association 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 already present in the bundle. @@ -496,29 +504,151 @@ 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. Abstract Security Block +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 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 @@ -528,43 +659,42 @@ 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. - Cipher Suite Id: + 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. - Cipher Suite Flags: + 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 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): Cipher Suite - Parameters Present Flag. + Bit 5 (the least-significant bit, 0x01): reserved. 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): 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 @@ -564,54 +694,23 @@ value of 0 indicates that the associated security block field MUST NOT be in the security block. 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). - Cipher Suite Parameters (Optional Field): - This field captures one or more cipher suite 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 cipher suite parameter. A single cipher suite - 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 cipher suite - 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 cipher suite parameters array is - illustrated in Figure 1. - - +----------------+----------------+ +----------------+ - | Parameter 1 | Parameter 2 | ... | Parameter N | - +------+---------+------+---------+ +------+---------+ - | Id | Value | Id | Value | | Id | Value | - +------+---------+------+---------+ +------+---------+ - - Figure 1: Cipher Suite 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 @@ -622,145 +721,142 @@ 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.10. + in Section 3.11. * Result Value. This field captures the value associated with the result. This field SHALL be represented by the applicable CBOR representation of the result value, in - accordance with Section 3.10. + accordance with Section 3.11. The logical layout of the security results array is illustrated in Figure 2. In this figure there are N security targets for this security block. The first security target contains M results and the Nth security target contains K results. +------------------------------+ +------------------------------+ | Target 1 | | Target N | +------------+----+------------+ +------------------------------+ | Result 1 | | Result M | ... | Result 1 | | Result K | +----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+ | Id | Value | | Id | Value | | Id | Value | | Id | Value | +----+-------+ +----+-------+ +----+-------+ +----+-------+ Figure 2: Security Results -3.7. Block Integrity Block +3.8. 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 Cipher Suite Id MUST be documented as an end-to-end - authentication-cipher suite or as an end-to-end error-detection- - cipher suite. + 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 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. + key information described in Section 3.11. 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 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 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. + SA. - 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 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 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 +3.9. 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 Cipher Suite Id MUST be documented as a confidentiality cipher - suite that supports authenticated encryption with associated data - (AEAD). + The Security Association Id MUST refer to a known SA that supports + a confidentiality cipher suite that supports authenticated + encryption with associated data (AEAD). - Additional information created by a cipher suite (such as - additional authenticated data) can be placed either in a security - result field or in the generated cipher-text. The determination - of where to place these data is a function of the cipher suite - used. + 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. 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. + key information described in Section 3.11. 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 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 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 +3.10. 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 @@ -792,73 +888,72 @@ 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.7, a BIB MUST NOT have a BCB as its + o As mentioned in Section 3.8, 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 possible insecure for a single security + 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. -3.10. Cipher Suite Parameter and Result Identification +3.11. SA Parameters and Result Identification - Cipher suite 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 cipher suite but do not need - to be unique across all cipher suites. Therefore, parameter ids and - security result ids are specified in the context of a cipher suite - definition. + 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. - Individual BPSec cipher suites SHOULD use existing registries of - identifiers and CBOR encodings, such as those defined in [RFC8152], - whenever possible. Cipher suites SHOULD define their own identifiers - and CBOR encodings when necessary. + 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. - A cipher suite can include multiple instances of the same identifier - for a parameter or result in a security block. 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. + 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. -3.11. BSP Block Examples +3.12. 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.11.1. Example 1: Constructing a Bundle with Security +3.12.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 +======================================+====+ @@ -893,21 +988,21 @@ 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.11.2. Example 2: Adding More Security At A New Node +3.12.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 @@ -988,25 +1083,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 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 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. 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. @@ -1506,28 +1601,29 @@ 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. 11.1. Bundle Block Types - This specification allocates two block types from the existing + This specification allocates three 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 12. References 12.1. Normative References