--- 1/draft-ietf-dtn-bpsec-04.txt 2017-07-02 11:13:12.429898553 -0700 +++ 2/draft-ietf-dtn-bpsec-05.txt 2017-07-02 11:13:12.501900264 -0700 @@ -1,18 +1,18 @@ Delay-Tolerant Networking E. Birrane Internet-Draft K. McKeever Intended status: Standards Track JHU/APL -Expires: September 13, 2017 March 12, 2017 +Expires: January 2, 2018 July 1, 2017 Bundle Protocol Security Specification - draft-ietf-dtn-bpsec-04 + draft-ietf-dtn-bpsec-05 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,229 +20,220 @@ 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 http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 13, 2017. + This Internet-Draft will expire on January 2, 2018. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2. Supported Security Services . . . . . . . . . . . . . . . 3 - 1.3. Specification Scope . . . . . . . . . . . . . . . . . . . 4 - 1.4. Related Documents . . . . . . . . . . . . . . . . . . . . 5 - 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Key Properties . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.1. Supported Security Services . . . . . . . . . . . . . . . 3 + 1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4 + 1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5 + 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 6 2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 7 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 7 2.4. User-Selected Cipher Suites . . . . . . . . . . . . . . . 8 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 8 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 + 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 8 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10 + 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 9 3.4. Target Identification . . . . . . . . . . . . . . . . . . 10 - 3.5. Block Representation . . . . . . . . . . . . . . . . . . 11 + 3.5. Block Representation . . . . . . . . . . . . . . . . . . 10 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. Parameters and Result Types . . . . . . . . . . . . . . . 17 - 3.11. BSP Block Example . . . . . . . . . . . . . . . . . . . . 20 - 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22 - 4.1. Technical Notes . . . . . . . . . . . . . . . . . . . . . 22 - 4.2. Primary Block Canonicalization . . . . . . . . . . . . . 23 - 4.3. Non-Primary-Block Canonicalization . . . . . . . . . . . 23 - 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24 - 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 24 - 5.1.1. Receiving BCB Blocks . . . . . . . . . . . . . . . . 24 - 5.1.2. Receiving BIB Blocks . . . . . . . . . . . . . . . . 25 - 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 26 - 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 26 - 7. Security Policy Considerations . . . . . . . . . . . . . . . 26 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 28 - 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 29 - 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 29 - 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29 - 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 31 - 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 31 - 9. Cipher Suite Authorship Considerations . . . . . . . . . . . 32 - 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 33 - 11. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 - 12.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 34 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 13.2. Informative References . . . . . . . . . . . . . . . . . 35 - Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 + 3.10. Cipher Suite Parameter and Result Identification . . . . 17 + 3.11. BSP Block Example . . . . . . . . . . . . . . . . . . . . 18 + 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 19 + 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 20 + 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 20 + 5.1.1. Receiving BCB Blocks . . . . . . . . . . . . . . . . 20 + 5.1.2. Receiving BIB Blocks . . . . . . . . . . . . . . . . 21 + 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 22 + 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 22 + 7. Security Policy Considerations . . . . . . . . . . . . . . . 23 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 24 + 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 25 + 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 25 + 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 26 + 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 27 + 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 27 + 9. Cipher Suite Authorship Considerations . . . . . . . . . . . 28 + 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 29 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 + 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 30 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 + 12.2. Informative References . . . . . . . . . . . . . . . . . 31 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction This document defines security features for the Bundle Protocol (BP) - [BPBIS]. This BP Security Specification (BPSec) is intended for use - in Delay Tolerant Networks (DTNs) to provide end-to-end security - services. - -1.1. Motivation + [BPBIS] and is intended for use in Delay Tolerant Networks (DTNs) to + provide end-to-end security services. The Bundle Protocol specification [BPBIS] defines DTN as referring to "a networking architecture providing communications in and/or through highly stressed environments" where "BP may be viewed as sitting at the application layer of some number of constituent networks, forming a store-carry-forward overlay network". The term "stressed" environment refers to multiple challenging conditions including intermittent connectivity, large and/or variable delays, asymmetric data rates, and high bit error rates. - There is a reasonable expectation that BP may be deployed in such a - way that a portion of the network might become compromised, posing - the usual security challenges related to confidentiality and - integrity. However, the stressed nature of the BP operating - environment imposes unique requirements such that the usual security - mechanisms to usual security challenges may not apply. For example, + The BP might be deployed such that portions of the network cannot be + trusted, posing the usual security challenges related to + confidentiality and integrity. However, the stressed nature of the + BP operating environment imposes unique conditions where usual + transport security mechanisms may not be sufficient. For example, the store-carry-forward nature of the network may require protecting - data at rest while also preventing unauthorized consumption of - critical resources such as storage space. The heterogeneous nature - of the networks comprising the BP overlay, and/or associated timing, - might prevent the establishment of an end-to-end session to provide a - context for a security service. The partitionability of a DTN might - prevent regular contact with a centralized security oracle (such as a - certificate authority). + data at rest, preventing unauthorized consumption of critical + resources such as storage space, and operating without regular + contact with a centralized security oracle (such as a certificate + authority). An end-to-end security service is needed that operates in all of the environments where the BP operates. -1.2. Supported Security Services +1.1. Supported Security Services BPSec provides end-to-end integrity and confidentiality services for BP bundles. - Integrity services ensure data within a bundle are not changed. Data - changes may be caused by processing errors, environmental conditions, - or intentional manipulation. An integrity service is one that - provides sufficient confidence to a data receiver that data has not - changed since its value was last asserted. + Integrity services ensure that protected data within a bundle are not + changed from the time they are provided to the network to the time + they are delivered at their destination. Data changes may be caused + by processing errors, environmental conditions, or intentional + manipulation. - Confidentiality services ensure that only authorized receivers can - view those data within a bundle identified as needing to be private - amongst the data source and data receivers. A confidentiality - services is one that provides confidence to a data receiver that - private data was not viewed by other nodes as the bundle traversed - the DTN. + Confidentiality services ensure that protected data is unintelligible + to nodes in the DTN, except for authorized nodes possessing special + information. Confidentiality, in this context, applies to the + contents of protected data and does not extend to hiding the fact + that protected data exist in the bundle. NOTE: Hop-by-hop authentication is NOT a supported security service in this specification, for three reasons. 1. The term "hop-by-hop" is ambiguous in a BP overlay, as nodes that are adjacent in the overlay may not be adjacent in physical connectivity. This condition is difficult or impossible to - predict in the overlay and therefore makes the concept of hop-by- - hop authentication difficult or impossible to enforce at the - overlay. + detect and therefore hop-by-hop authentication is difficult or + impossible to enforce. 2. Networks in which BPSec may be deployed may have a mixture of security-aware and not-security-aware nodes. Hop-by-hop authentication cannot be deployed in a network if adjacent nodes in the network have different security capabilities. - 3. Hop-by-hop authentication can be viewed as a special case of data - integrity. As such, a version of authentication can be achieved - by using the integrity mechanisms defined in this specification. + 3. Hop-by-hop authentication is a special case of data integrity and + can be achieved with the integrity mechanisms defined in this + specification. Therefore, a separate authentication service is + not necessary. -1.3. Specification Scope +1.2. Specification Scope This document defines the security services provided by the BPSec. This includes the data specification for representing these services as BP extension blocks, and the rules for adding, removing, and - processing these blocks at various points in the bundle's traversal - of the DTN. + processing these blocks at various points during the bundle's + traversal of the DTN. BPSec applies only to those nodes that implement it, known as "security-aware" nodes. There might be other nodes in the DTN that do not implement BPSec. While all nodes in a BP overlay can exchange bundles, BPSec security operations can only happen at BPSec security- aware nodes. This specification does not address individual cipher suite implementations. 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. - The definition and enumeration of cipher suites is assumed to be - undertaken in other, separate specification documents. + 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. 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. This specification does not address how to combine the BPSec security blocks with other protocols, other BP extension blocks, or other best practices to achieve security in any particular network implementation. -1.4. Related Documents +1.3. Related Documents This document is best read and understood within the context of the following other DTN documents: "Delay-Tolerant Networking Architecture" [RFC4838] defines the architecture for DTNs and identifies certain security assumptions made by existing Internet protocols that are not valid in a DTN. - The Bundle Protocol [BPBIS] defines the format and processing of the - bundles that both carry the data and the security services operating - on those data. This document also defines the extension block format - used to capture BPSec security blocks. + The Bundle Protocol [BPBIS] defines the format and processing of + bundles, defines the extension block format used to represent BPSec + security blocks, and defines the canonicalization algorithms used by + this specification. The Bundle Security Protocol [RFC6257] and Streamlined Bundle - Security Protocol [SBSP] documents introduced the concepts of BP - security blocks for security services in a DTN. The BPSec is a + Security Protocol [SBSP] documents introduced the concepts of using + BP extension blocks for security services in a DTN. The BPSec is a continuation and refinement of these documents. -1.5. Terminology +1.4. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [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 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 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. o Path - the ordered sequence of nodes through which a bundle passes on its way from Source to Destination. The path is not @@ -254,42 +245,39 @@ 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. o Security Source - a bundle node that adds a security block to a - bundle. + bundle. 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. - o Source - the node which originates a bundle. The Node ID of the - BPA originating the bundle. - -2. Key Properties +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 and defines the key properties guiding design - decisions for the security services provided by this specification. + 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. As such, each security block within a bundle MUST be - associated with a specific security operation. + 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 variety of data that may augment or annotate the payload, or otherwise provide information necessary for the proper processing of a bundle along a path. Therefore, applying a single level and type of security across an entire bundle fails to recognize that blocks in a bundle may represent different types of information with different security needs. @@ -348,25 +337,25 @@ Some waypoints may understand security blocks but refuse to process them unless they are the bundle destination. 2.4. User-Selected Cipher Suites 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 SHA-256 based hash for integrity - whereas other users may prefer a SHA-384 hash instead. The security - services defined in this specification MUST provide a mechanism for - identifying what cipher suite has been used to populate a security - block. + example, some users might prefer a SHA2 hash function for integrity + whereas other users may prefer a SHA3 hash function instead. The + security services defined in this specification MUST provide a + mechanism for identifying what cipher suite 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 @@ -378,64 +368,64 @@ 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 security target(s). The integrity information in the BIB MAY be verified by any node in between the BIB security source and the bundle destination. Security-aware waypoints may add or remove BIBs from bundles in accordance with their security policy. - The BCB indicates that the security target(s) has been encrypted, - in whole or in part, at the BCB security source in order to - protect its content while in transit. The BCB may be decrypted by - security-aware nodes in the network, up to and including the - bundle destination, as a matter of security policy. + The BCB indicates that the security target(s) have been encrypted + at the BCB security source in order to protect its content while + in transit. The BCB may be decrypted by security-aware nodes in + the network, up to and including the bundle destination, as a + matter of security policy. 3.2. Uniqueness Security operations in a bundle MUST be unique - the same security service MUST NOT be applied to a security target more than once in a bundle. Since a security operation is represented as a security block, this limits what security blocks may be added to a bundle: if adding a security block to a bundle would cause some other security block to no longer represent a unique security operation then the new block MUST NOT be added. 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. 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 cannot both - be present in the same bundle at the same time. + 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. 3.3. Target Multiplicity - Under special circumstances, a single security block can represent + 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 may be represented by a single security block if and only if the following conditions are true. o The security operations apply the same security service. For example, they are all integrity operations or all confidentiality @@ -461,22 +451,23 @@ When the security block is processed all security operations represented by the security block MUST be applied/evaluated at that time. 3.4. Target Identification A security target is a block in the bundle to which a security service applies. This target MUST be uniquely and unambiguously identifiable when processing a security block. The definition of the extension block header from [BPBIS] provides a "Block Number" field - for exactly this purpose. Therefore, a security target in a security - block MUST be represented as the Block Number of the target block. + suitable for this purpose. Therefore, a security target in a + security block MUST be represented as the Block Number of the target + block. 3.5. Block Representation Each security block uses the Canonical Bundle Block Format as defined in [BPBIS]. That is, each security block is comprised of the following elements: o Block Type Code o Block Number @@ -499,36 +489,38 @@ 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 which they MUST appear. Security Targets: - This field identifiers the block or blocks that are the target - of the security operation(s) represented by this security - block. Each security target is identified as the Block Number - of the target block. 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 item. + This field identifies the block(s) targetted 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: 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: - This field identifiers which optional fields are present in the + 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. @@ -552,102 +544,112 @@ array in accordance with [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 type and value of the parameter, as follows. + a 2-tuple of the id and value of the parameter, as follows. - * Parameter Type. This field identifiers which cipher suite + * Parameter Id. This field identifies which cipher suite parameter is being specified. This field SHALL be - represented as a CBOR unsigned integer. Potential parameter - types are described in Section 3.10. Other specifications - MAY define additional parameter types for use in this field. + 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 type. These - specifications are given in Section 3.10 for parameter types - defined in this specification. Other specifications that - define other parameter types MUST include the appropriate - CBOR encoding of the parameter value. + applicable CBOR representation of the parameter, in + accordance with Section 3.10. - Therefore, this field SHALL be represented as a CBOR array of - CBOR arrays. + 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 in this security block. This field - SHALL be represented as a CBOR array. Each entry in this array - represents a "target list" of security results for a specific - security target. There MUST be one "target list" for each - entry in the Security Targets field and target lists in the - Security Results field MUST be in the same order as the - Security Targets field (e.g., the first "target list" MUST hold - results for the first entry in the Security Targets field, and - so on). + 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 + entry in this array for each entry in the Security Targets + field of the security block. - A "target list" is also represented as a CBOR array of - individual security results for that target. An individual - security result is also represented as a CBOR array comprising - the 2-tuple of the result type and result value, defined as - follows. + 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 Type. This field captures the type of security - result. Some security result types capture the primary + * 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 the cipher suite + additional annotative information from cipher suite processing. This field SHALL be represented as a CBOR - unsigned integer. Potential result types are described in - Section 3.10. Other specifications MAY define additional - result types for use in this field. + unsigned integer. Security result ids will be as specified + in Section 3.10. * Result Value. This field captures the value associated with - this result for this target. This field SHALL be - represented by the applicable CBOR representation of the - result type. These specifications are given in Section 3.10 - for result types defined in this specification. Other - specifications that define other result types MUST include - the appropriate CBOR encoding of the result value. + the result. This field SHALL be represented by the + applicable CBOR representation of the result value, in + accordance with Section 3.10. + + The logical layout of the security results array is illustrated + in Figure 2. In this figure there are N security targets for + this security block. The first security target contains M + results and the Nth security target contains K results. + + +------------------------------+ +------------------------------+ + | Target 1 | | Target N | + +------------+----+------------+ +------------------------------+ + | Result 1 | | Result M | ... | Result 1 | | Result K | + +----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+ + | Id | Value | | Id | Value | | Id | Value | | Id | Value | + +----+-------+ +----+-------+ +----+-------+ +----+-------+ + + Figure 2: Security Results 3.7. Block Integrity Block A BIB is a bundle extension block with the following characteristics. - o The Block Type Code value is as specified in Section 12.1. + 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 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 also be specified as part of key information described in Section 3.10. - o The cipher suite MAY process less than the entire security target. - If the cipher suite processes less than the complete, original - security target, the cipher suite parameters MUST specify which - bytes of the security target are protected. - 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 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 @@ -660,21 +662,21 @@ 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 12.1. + 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. @@ -724,26 +726,20 @@ is larger than the plain-text, overflow bytes MUST be placed in overflow parameters in the Security Result 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 The cipher suite MAY process less than the entire original - security target body data. If the cipher suite processes less - than the complete, original security target body data, the BCB for - that security target MUST specify, as part of the cipher suite - parameters, which bytes of the body data are protected. - o The BCB block processing control flags MAY 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. o A BCB MAY include information as part of additional authenticated data to address parts of the target block that are not converted to cipher-text. 3.9. Block Interactions @@ -786,119 +782,46 @@ security results. 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. -3.10. Parameters and Result Types - - Cipher suite parameters and security results may capture multiple - types of information in a security block. This section identifies a - set of parameters and results that are available in any BPSec - implementation for use by any cipher suite. Individual cipher suites - MAY define additional parameters and results. A cipher suite MAY - include multiple instances of the same type of parameter or result in - a security block. - - Parameters and results are represented using CBOR, and any - identification of a new parameter or result type MUST include how the - value of the type will be represented using the CBOR specification. - Types themselves are always represented as a CBOR unsigned integer. - - Cipher suite parameter types, as defined by this specification, are - as follows. - - Cipher Suite Parameter Types. - - +------+----------------+--------------------------+----------------+ - | Type | Name | Description | CBOR | - | | | | Representation | - +------+----------------+--------------------------+----------------+ - | 0 | Initialization | A random value, | Byte String | - | | Vector | typically eight to | | - | | | sixteen bytes. | | - +------+----------------+--------------------------+----------------+ - | 1 | Key | Material encoded or | Byte String | - | | Information | protected by the key | | - | | | management system and | | - | | | used to transport an | | - | | | ephemeral key protected | | - | | | by a long-term key. | | - +------+----------------+--------------------------+----------------+ - | 2 | Content Range | Pair of Unsigned | CBOR Array | - | | | Integers (offset,length) | comprising a | - | | | specifying the range of | 2-tuple of | - | | | payload bytes to which | CBOR unsigned | - | | | an operation applies. | integers. | - | | | The offset MUST be the | | - | | | offset within the | | - | | | original bundle, even if | | - | | | the current bundle is a | | - | | | fragment. | | - +------+----------------+--------------------------+----------------+ - | 3 | Salt | An IV-like value used by | Byte Array | - | | | certain confidentiality | | - | | | suites. | | - +------+----------------+--------------------------+----------------+ - | 4-31 | Reserved | Reserve for future BPSec | | - | | | protocol expansion | | - +------+----------------+--------------------------+----------------+ - | >= | Unassigned | Unassigned by this | | - | 32 | | specification. Can be | | - | | | assigned by cipher suite | | - | | | specifications. | | - +------+----------------+--------------------------+----------------+ - - Table 1 - - Security result parameter types, as defined by this specification, - are as follows. +3.10. Cipher Suite Parameter and Result Identification - Security Result Types. + 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. - +------+----------------+--------------------------+----------------+ - | Type | Name | Description | CBOR | - | | | | Representation | - +------+----------------+--------------------------+----------------+ - | 0 | Integrity | Result of BIB digest or | Byte String | - | | Signatures | other signing operation. | | - +------+----------------+--------------------------+----------------+ - | 1 | BCB Integrity | Output from certain | Byte String | - | | Check Value | confidentiality cipher | | - | | (ICV) / | suite operations to be | | - | | Authentication | used at the destination | | - | | Tag | to verify that the | | - | | | protected data has not | | - | | | been modified. This | | - | | | value MAY contain | | - | | | padding if required by | | - | | | the cipher suite. | | - +------+----------------+--------------------------+----------------+ - | 2-31 | Reserved | Reserve for future BPSec | | - | | | protocol expansion | | - +------+----------------+--------------------------+----------------+ - | >= | Unassigned | Unassigned by this | | - | 32 | | specification. Can be | | - | | | assigned by cipher suite | | - | | | specifications. | | - +------+----------------+--------------------------+----------------+ + Individual BPSec cipher suites SHOULD use existing registries of + identifiers and CBOR encodings, such as those defined in [COSE], + whenever possible. Cipher suites MAY define their own identifiers + and CBOR encodings when necessary. - Table 2 + A cipher suite MAY 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. 3.11. BSP Block Example An example of BPSec blocks applied to a bundle is illustrated in - Figure 1. In this figure the first column represents blocks within a + Figure 3. In this figure 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. Block in Bundle ID +===================================+====+ | Primary Block | B1 | +-----------------------------------+----+ | BIB | B2 | | OP(integrity, target=B1) | | +-----------------------------------+----+ @@ -914,21 +837,21 @@ +-----------------------------------+----+ | BCB | B7 | | OP(confidentiality,targets=B8,B9) | | +-----------------------------------+----+ | BIB (encrypted by B7) | B8 | | OP(integrity, target=B9) | | +-----------------------------------+----| | Payload Block | B9 | +-----------------------------------+----+ - Figure 1: Sample Use of BPSec Blocks + Figure 3: Sample Use of BPSec Blocks In this example a bundle has four non-security-related blocks: the primary block (B1), two extension blocks (B4,B6), and a payload block (B9). The following security applications are applied to this bundle. o An integrity signature applied to the canonicalized primary block. This is accomplished by a single BIB (B2). o Confidentiality for the first extension block (B4). This is @@ -946,105 +869,58 @@ o Confidentiality for the payload block and it's integrity signature. This is accomplished by a BCB block, B7, encrypting B8 and B9. In this case, the security source, key parameters, and service are identical, so a single security block MAY be used for this purpose, rather than requiring two BCBs one to encrypt B8 and one to encrypt B9. 4. Canonical Forms - By definition, an integrity service determines whether any aspect of - a block was changed from the moment the security service was applied - at the security source until the point of evaluation. To - successfully verify the integrity of a block, the data passed to the - verifying cipher suite MUST be the same bits, in the same order, as - those passed to the signature-generating cipher suite at the security - source. - - This section provides guidance on how to create a canonical form for - each type of block in a bundle. This form MUST be used when - generating inputs to cipher suites for use by BPSec blocks. + 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 + representation of a target block. -4.1. Technical Notes + Canonical forms are not transmitted, they are used to generate input + to a cipher suite for security processing at a security-aware node. - The following technical considerations hold for all canonicalizations - in this section. + The canonicalization of the primary block is as specified in [BPBIS]. - o Any numeric fields defined as variable-length MUST be expanded to - their largest unpacked form before being used by a cipher suite. - If a field does not specify a maximum size, a maximum size of 32 - bits for integer and 64 bits for floating point values SHALL be - assumed. + All non-primary blocks share the same block structure and are + canonicalized as specified in [BPBIS] with the following exception. - o Canonical forms are not transmitted, they are used to generate - input to a cipher suite for security processing at a security- - aware node. + o If the service being applied is a confidentiality service, then + the Block Type Code, Block Number, Block Processing Control Flags, + CRC Type and CRC Field (if present), and Block Data Length fields + MUST NOT be included in the canonicalization. Confidentiality + services are used solely to convert the Block Type Specific Data + 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. - o 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. + 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. - o Cipher suites MAY define their own canonicalization algorithms and + 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. -4.2. Primary Block Canonicalization - - The canonicalization of the primary block is as specified in [BPBIS] - with the following exceptions. - - o The following Bundle Processing Control Flags MAY change as a - bundle transits the DTN without indicating an integrity error and, - therefore, MUST NOT be included in the canonicalization of the - primary block. - - * Bundle is a fragment. (Bit 15, 0x0001) - - * Custody transfer requested for this bundle. (Bit 12, 0x0008) - - * Reserved (Bits 0-2, 0xE000) - - Regardless of the value of these flags in the primary block, they - MUST be set to 0 when canonicalized for security processing. - - o The CRC field MAY change at each hop - for example, if a bundle - becomes fragmented, each fragment will have a different CRC value - from the original signed primary block. As such, this field MUST - NOT be included in the canonicalization. - -4.3. Non-Primary-Block Canonicalization - - All non-primary blocks (NPBs) share the same block structure and are - canonicalized as specified in [BPBIS] with the following exceptions. - - o If the service being applied is a confidentiality service, then - the Block Type Code, Block Number, Block Processing Control Flags, - CRC Type and CRC Field (if present), and Block Data Length fields - MUST NOT be included in the canonicalization. Confidentiality - services are used to convert the Block Type Specific Data Fields - from plain-text to cipher-text. - - o The Block Type Specific Data Field is included, without - modification, for both integrity and confidentiality services, - with the exception that in some cases only a portion of the - payload data is to be processed. In such a case, only those bytes - are included in the canonical form and additional cipher suite - parameters are required to specify which part of the field is - included. - 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. o All BCB blocks in the bundle MUST be evaluated prior to evaluating @@ -1064,28 +940,28 @@ directed to do so as a matter of security policy. If the security policy of a security-aware node specifies that a bundle should have applied confidentiality to a specific security target and no such BCB is present in the bundle, then the node MUST process this security target in accordance with the security policy. This MAY involve removing the security target from the bundle. If the removed security target is the payload block, the bundle MAY be discarded. - If the relevant parts of an encrypted payload block cannot be - decrypted (i.e., the decryption key cannot be deduced or decryption - fails), then the bundle MUST be discarded and processed no further. - If an encrypted security target other than the payload block cannot - be decrypted then the associated security target and all security - blocks associated with that target MUST be discarded and processed no - further. In both cases, requested status reports (see [BPBIS]) MAY - be generated to reflect bundle or block deletion. + If an encrypted payload block cannot be decrypted (i.e., the + decryption key cannot be deduced or decryption fails), then the + bundle MUST be discarded and processed no further. If an encrypted + security target other than the payload block cannot be decrypted then + the associated security target and all security blocks associated + with that target MUST be discarded and processed no further. In both + cases, requested status reports (see [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 targets, all security targets MUST be processed when the BCB is processed. Errors and other processing steps SHALL be made as if each security target had been represented by an individual BCB with a single security target. @@ -1154,23 +1030,23 @@ MAY be handled by other mechanisms outside of the BPSec protocol or by applying BPSec blocks in coordination with an encapsulation mechanism. 6. Key Management There exist a myriad of ways to establish, communicate, and otherwise manage key information in a DTN. Certain DTN deployments might follow established protocols for key management whereas other DTN deployments might require new and novel approaches. BPSec assumes - that key management is handled as a separate part of network design - and this specification neither defines nor requires a specific key - management strategy. + that key management is handled as a separate part of network + management and this specification neither defines nor requires a + specific key management strategy. 7. Security Policy Considerations When implementing BPSec, several policy decisions must be considered. This section describes key policies that affect the generation, forwarding, and receipt of bundles that are secured using this specification. No single set of policy decisions is envisioned to work for all secure DTN deployments. o If a bundle is received that contains more than one security @@ -1444,27 +1320,26 @@ 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 specifications. - o New Parameters. Cipher suites MAY define new parameter types that - may appear in security blocks and used to configure the cipher - suite. + o Cipher Suite Parameters. Cipher suites MUST define their + parameter ids, the data types of those parameters, and their CBOR + encoding. - o New Results. Cipher suites MAY define new security result types - that may appear in security blocks and capture the outputs of the - cipher suite. + o Security Results. Cipher suites MUST define their security result + ids, the data types of those results, and their CBOR encoding. o New Canonicalizations. Cipher suites MAY define new canonicalization algorithms as necessary. 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 MAY co-exist within a bundle and MAY be considered in conformance with BPSec if each of the following @@ -1505,67 +1380,62 @@ Additionally, policy considerations for the management, monitoring, 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. Conformance - - All implementations are strongly RECOMMENDED to provide some method - of hop-by-hop verification by generating a hash to some canonical - form of the bundle and placing an integrity signature on that form - using a BIB. - -12. IANA Considerations +11. IANA Considerations - Registries of Cipher Suite IDs, Cipher Suite Flags, Cipher Suite - Parameter Types, and Security Result Types will be required. + A registry of cipher suite identifiers will be required. -12.1. Bundle Block Types +11.1. Bundle Block Types 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 | Block Integrity Block | This document | | TBD | Block Confidentiality Block | This document | +-------+-----------------------------+---------------+ - Table 3 + Table 1 -13. References +12. References -13.1. Normative References +12.1. Normative References [BPBIS] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol", draft-ietf-dtn-bpbis-06 (work in progress), July 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol IANA Registries", RFC 6255, May 2011. -13.2. Informative References +12.2. Informative References + + [COSE] Schaad, J., "CBOR Object Signing and Encryption (COSE)", + draft-ietf-cose-msg-24 (work in progress), November 2016. [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, May 2011. [SBSP] Birrane, E., "Streamlined Bundle Security Protocol",