--- 1/draft-ietf-dtn-bpsec-16.txt 2020-01-22 20:13:19.952225135 -0800 +++ 2/draft-ietf-dtn-bpsec-17.txt 2020-01-22 20:13:20.028227065 -0800 @@ -1,19 +1,19 @@ Delay-Tolerant Networking E. Birrane Internet-Draft K. McKeever Obsoletes: 6257 (if approved) JHU/APL -Intended status: Standards Track January 21, 2020 -Expires: July 24, 2020 +Intended status: Standards Track January 22, 2020 +Expires: July 25, 2020 Bundle Protocol Security Specification - draft-ietf-dtn-bpsec-16 + draft-ietf-dtn-bpsec-17 Abstract This document defines a security protocol providing end to end data integrity and confidentiality services for the Bundle Protocol. This document is an update of the protocol described in RFC 6257, reflecting lessons learned. For this reason it obsoletes RFC 6257, an IRTF-stream document. @@ -25,21 +25,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 July 24, 2020. + This Internet-Draft will expire on July 25, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -65,52 +65,52 @@ 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 10 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11 3.4. Target Identification . . . . . . . . . . . . . . . . . . 12 3.5. Block Representation . . . . . . . . . . . . . . . . . . 12 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17 - 3.10. Parameter and Result Identification . . . . . . . . . . . 18 + 3.10. Parameter and Result Identification . . . . . . . . . . . 19 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 19 3.11.1. Example 1: Constructing a Bundle with Security . . . 19 3.11.2. Example 2: Adding More Security At A New Node . . . 20 - 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 20 - 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 21 - 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 21 - 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 21 - 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 22 - 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 23 - 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 24 - 7. Security Policy Considerations . . . . . . . . . . . . . . . 24 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 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 . . . . . . . . . . . . . . . . 27 - 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 28 - 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 29 - 9. Security Context Considerations . . . . . . . . . . . . . . . 29 - 9.1. Identification and Configuration . . . . . . . . . . . . 29 - 9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 30 + 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22 + 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 23 + 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23 + 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23 + 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24 + 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 25 + 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 25 + 7. Security Policy Considerations . . . . . . . . . . . . . . . 25 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 27 + 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 28 + 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 28 + 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29 + 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30 + 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 30 + 9. Security Context Considerations . . . . . . . . . . . . . . . 31 + 9.1. Identification and Configuration . . . . . . . . . . . . 31 + 9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 32 - 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 32 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 33 - 11.2. Security Context Identifiers . . . . . . . . . . . . . . 33 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 12.2. Informative References . . . . . . . . . . . . . . . . . 34 - Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 + 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 33 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 + 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 34 + 11.2. Security Context Identifiers . . . . . . . . . . . . . . 35 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 + 12.2. Informative References . . . . . . . . . . . . . . . . . 36 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36 + 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 @@ -641,20 +641,26 @@ in Section 3.10. * Parameter Value. This field captures the value associated with this parameter. This field SHALL be represented by the applicable CBOR representation of the parameter, in accordance with Section 3.10. The logical layout of the parameters array is illustrated in Figure 1. + +----------------+----------------+ +----------------+ + | Parameter 1 | Parameter 2 | ... | Parameter N | + +------+---------+------+---------+ +------+---------+ + | Id | Value | Id | Value | | Id | Value | + +------+---------+------+---------+ +------+---------+ + Figure 1: Security Context Parameters Security Results: This field captures the results of applying a security service to the security targets of the security block. This field SHALL be represented as a CBOR array of target results. Each entry in this array represents the set of security results for a specific security target. The target results MUST be ordered identically to the Security Targets field of the security block. This means that the first set of target results in this @@ -679,20 +685,28 @@ * 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. 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 11.1. o The Block Type Specific Data Fields follow the structure of the ASB. @@ -874,20 +888,37 @@ 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, the second extension block, and the payload. The bundle source also wishes to provide confidentiality for the first extension block. The resultant bundle is illustrated in Figure 3 and the security actions are described below. + Block in Bundle ID + +======================================+====+ + | Primary Block | B1 | + +--------------------------------------+----+ + | BIB | B2 | + | OP(integrity, targets=B1, B5, B6) | | + +--------------------------------------+----+ + | BCB | B3 | + | OP(confidentiality, target=B4) | | + +--------------------------------------+----+ + | Extension Block (encrypted) | B4 | + +--------------------------------------+----+ + | Extension Block | B5 | + +--------------------------------------+----+ + | Payload Block | B6 | + +--------------------------------------+----+ + Figure 3: Security at Bundle Creation The following security actions were applied to this bundle at its time of creation. o An integrity signature applied to the canonicalized primary block (B1), the second extension block (B5) and the payload block (B6). This is accomplished by a single BIB (B2) with multiple targets. A single BIB is used in this case because all three targets share a security source, security context, and security context @@ -911,20 +942,43 @@ extension block and the bundle payload. The waypoint security policy is to allow existing BIBs for these blocks to persist, as they may be required as part of the security policy at the bundle destination. The resultant bundle is illustrated in Figure 4 and the security actions are described below. Note that block IDs provided here are ordered solely for the purpose of this example and not meant to impose an ordering for block creation. The ordering of blocks added to a bundle MUST always be in compliance with [I-D.ietf-dtn-bpbis]. + Block in Bundle ID + +======================================+====+ + | Primary Block | B1 | + +--------------------------------------+----+ + | BIB | B2 | + | OP(integrity, targets=B1) | | + +--------------------------------------+----+ + | BIB (encrypted) | B7 | + | OP(integrity, targets=B5, B6) | | + +--------------------------------------+----+ + | BCB | B8 | + | OP(confidentiality, target=B5,B6,B7) | | + +--------------------------------------+----+ + | BCB | B3 | + | OP(confidentiality, target=B4) | | + +--------------------------------------+----+ + | Extension Block (encrypted) | B4 | + +--------------------------------------+----+ + | Extension Block (encrypted) | B5 | + +--------------------------------------+----+ + | Payload Block (encrypted) | B6 | + +--------------------------------------+----+ + Figure 4: Security At Bundle Forwarding The following security actions were applied to this bundle prior to its forwarding from the waypoint node. o Since the waypoint node wishes to encrypt blocks B5 and B6, it MUST also encrypt the BIBs providing plain-text integrity over those blocks. However, BIB B2 could not be encrypted in its entirety because it also held a signature for the primary block (B1). Therefore, a new BIB (B7) is created and security results @@ -1394,25 +1448,24 @@ of contexts can be defined with each context supporting few, if any, parameters. Security Context Examples +---------+------------+--------------------------------------------+ | Context | Parameters | Definition | | Id | | | +---------+------------+--------------------------------------------+ | 1 | Key, IV | AES-GCM-256 cipher suite with provided | - | | | ephemeral key and | - | | | initialization vector. | + | | | ephemeral key and initialization vector. | | 2 | IV | AES-GCM-256 cipher suite with | - | | | predetermined key and predetermined | - | | | key rotation policy. | + | | | predetermined key and predetermined key | + | | | rotation policy. | | 3 | Nil | AES-GCM-256 cipher suite with all info | | | | predetermined. | +---------+------------+--------------------------------------------+ Table 1 9.2. Authorship Developers or implementers should consider the diverse performance and conditions of networks on which the Bundle Protocol (and @@ -1622,28 +1675,26 @@ The following participants contributed technical material, use cases, and useful thoughts on the overall approach to this security specification: Scott Burleigh of the Jet Propulsion Laboratory, Amy Alford and Angela Hennessy of the Laboratory for Telecommunications Sciences, and Angela Dalton and Cherita Corbett of the Johns Hopkins University Applied Physics Laboratory. Authors' Addresses Edward J. Birrane, III - The Johns Hopkins University Applied - Physics Laboratory + The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Rd. Laurel, MD 20723 US Phone: +1 443 778 7423 Email: Edward.Birrane@jhuapl.edu Kenneth McKeever - The Johns Hopkins University Applied - Physics Laboratory + The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Rd. Laurel, MD 20723 US Phone: +1 443 778 2237 Email: Ken.McKeever@jhuapl.edu