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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/