draft-ietf-dtn-bpsec-23.txt   draft-ietf-dtn-bpsec-24.txt 
Delay-Tolerant Networking E. Birrane Delay-Tolerant Networking E. Birrane
Internet-Draft K. McKeever Internet-Draft K. McKeever
Intended status: Standards Track JHU/APL Intended status: Standards Track JHU/APL
Expires: April 28, 2021 October 25, 2020 Expires: May 5, 2021 November 1, 2020
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-23 draft-ietf-dtn-bpsec-24
Abstract Abstract
This document defines a security protocol providing data integrity This document defines a security protocol providing data integrity
and confidentiality services for the Bundle Protocol. and confidentiality services for the Bundle Protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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 April 28, 2021. This Internet-Draft will expire on May 5, 2021.
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 21 skipping to change at page 2, line 21
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 7 2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 7 2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 7
2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8 2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8
2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 9 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 9
2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9
2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . 12
3.4. Target Identification . . . . . . . . . . . . . . . . . . 12 3.4. Target Identification . . . . . . . . . . . . . . . . . . 13
3.5. Block Representation . . . . . . . . . . . . . . . . . . 13 3.5. Block Representation . . . . . . . . . . . . . . . . . . 13
3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 13 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 13
3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 16 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 16
3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 17 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 17
3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 18 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 18
3.10. Parameter and Result Identification . . . . . . . . . . . 19 3.10. Parameter and Result Identification . . . . . . . . . . . 20
3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 20 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 20
3.11.1. Example 1: Constructing a Bundle with Security . . . 20 3.11.1. Example 1: Constructing a Bundle with Security . . . 20
3.11.2. Example 2: Adding More Security At A New Node . . . 21 3.11.2. Example 2: Adding More Security At A New Node . . . 21
4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 23 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 23
5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24
5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 24 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 24
5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 24 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 24
5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 25 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 25
5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 26 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 26
6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 27 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 7, line 10 skipping to change at page 7, line 10
one or more security blocks in a bundle. Also, the Node ID of one or more security blocks in a bundle. Also, the Node ID of
that node. that node.
o Security Block - a BPSec extension block in a bundle. o Security Block - a BPSec extension block in a bundle.
o Security Context - the set of assumptions, algorithms, o Security Context - the set of assumptions, algorithms,
configurations and policies used to implement security services. configurations and policies used to implement security services.
o Security Operation - the application of a given security service o Security Operation - the application of a given security service
to a security target, notated as OP(security service, security to a security target, notated as OP(security service, security
target). For example, OP(confidentiality, payload). Every target). For example, OP(bcb-confidentiality, payload). Every
security operation in a bundle MUST be unique, meaning that a security operation in a bundle MUST be unique, meaning that a
given security service can only be applied to a security target given security service can only be applied to a security target
once in a bundle. A security operation is implemented by a once in a bundle. A security operation is implemented by a
security block. security block.
o Security Service - a process that gives some protection to a o Security Service - a process that gives some protection to a
security target. For example, this specification defines security security target. For example, this specification defines security
services for plain text integrity, plain text confidentiality, and services for plain text integrity (bib-integrity), and
cipher text integrity. authenticated plain text confidentiality with additional
authenticated data (bcb-confidentiality).
o Security Source - a bundle node that adds a security block to a o Security Source - a bundle node that adds a security block to a
bundle. Also, the Node ID of that node. bundle. Also, the Node ID of that node.
o Security Target - the block within a bundle that receives a o Security Target - the block within a bundle that receives a
security service as part of a security operation. security service as part of a security operation.
2. Design Decisions 2. Design Decisions
The application of security services in a DTN is a complex endeavor The application of security services in a DTN is a complex endeavor
skipping to change at page 11, line 5 skipping to change at page 11, line 5
block. block.
This uniqueness requirement ensures that there is no ambiguity This uniqueness requirement ensures that there is no ambiguity
related to the order in which security blocks are processed or how related to the order in which security blocks are processed or how
security policy can be specified to require certain security services security policy can be specified to require certain security services
be present in a bundle. be present in a bundle.
Using the notation OP(service, target), several examples illustrate Using the notation OP(service, target), several examples illustrate
this uniqueness requirement. this uniqueness requirement.
o Signing the payload twice: The two operations OP(integrity, o Signing the payload twice: The two operations OP(bib-integrity,
payload) and OP(integrity, payload) are redundant and MUST NOT payload) and OP(bib-integrity, payload) are redundant and MUST NOT
both be present in the same bundle at the same time. both be present in the same bundle at the same time.
o Signing different blocks: The two operations OP(integrity, o Signing different blocks: The two operations OP(bib-integrity,
payload) and OP(integrity, extension_block_1) are not redundant payload) and OP(bib-integrity, extension_block_1) are not
and both may be present in the same bundle at the same time. redundant and both may be present in the same bundle at the same
Similarly, the two operations OP(integrity, extension_block_1) and time. Similarly, the two operations OP(bib-integrity,
OP(integrity,extension_block_2) are also not redundant and may extension_block_1) and OP(bib-integrity, extension_block_2) are
both be present in the bundle at the same time. 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, o Different Services on same block: The two operations OP(bib-
payload) and OP(confidentiality, payload) are not inherently integrity, payload) and OP(bcb-confidentiality, payload) are not
redundant and may both be present in the bundle at the same time, inherently redundant and may both be present in the bundle at the
pursuant to other processing rules in this specification. same time, pursuant to other processing rules in this
specification.
o Different services from different block types: The notation
OP(service, target) refers specifically to a security block, as
the security block is the embodiment of a security service applied
to a security target in a bundle. Were some Other Security Block
(OSB) to be defined providing an integrity service, then the
operations OP(bib-integrity, target) and OP(osb-integrity, target)
MAY both be present in the same bundle if so allowed by the
definition of the OSB, as discussed in Section 10.
NOTES: NOTES:
A security block may be removed from a bundle as part of security A security block may be removed from a bundle as part of security
processing at a waypoint node with a new security block being processing at a waypoint node with a new security block being
added to the bundle by that node. In this case, conflicting added to the bundle by that node. In this case, conflicting
security blocks never co-exist in the bundle at the same time and security blocks never co-exist in the bundle at the same time and
the uniqueness requirement is not violated. the uniqueness requirement is not violated.
A cipher text integrity mechanism (such as associated A cipher text integrity mechanism (such as associated
skipping to change at page 17, line 5 skipping to change at page 17, line 17
inferred according to security policy and MAY default to the inferred according to security policy and MAY default to the
bundle source. The security source MAY be specified as part of bundle source. The security source MAY be specified as part of
security context parameters described in Section 3.10. security context parameters described in Section 3.10.
Notes: Notes:
o Designers SHOULD carefully consider the effect of setting flags o Designers SHOULD carefully consider the effect of setting flags
that either discard the block or delete the bundle in the event that either discard the block or delete the bundle in the event
that this block cannot be processed. that this block cannot be processed.
o Since OP(integrity, target) is allowed only once in a bundle per o Since OP(bib-integrity, target) is allowed only once in a bundle
target, it is RECOMMENDED that users wishing to support multiple per target, it is RECOMMENDED that users wishing to support
integrity mechanisms for the same target define a multi-result multiple integrity mechanisms for the same target define a multi-
security context. Such a context could generate multiple security result security context. Such a context could generate multiple
results for the same security target using different integrity- security results for the same security target using different
protection mechanisms or different configurations for the same integrity-protection mechanisms or different configurations for
integrity-protection mechanism. the same integrity-protection mechanism.
o A BIB is used to verify the plain text integrity of its security o A BIB is used to verify the plain text integrity of its security
target. However, a single BIB MAY include security results for target. However, a single BIB MAY include security results for
blocks other than its security target when doing so establishes a blocks other than its security target when doing so establishes a
needed relationship between the BIB security target and other needed relationship between the BIB security target and other
blocks in the bundle (such as the primary block). blocks in the bundle (such as the primary block).
o Security information MAY be checked at any hop on the way to the o Security information MAY be checked at any hop on the way to the
bundle destination that has access to the required keying bundle destination that has access to the required keying
information, in accordance with Section 3.9. information, in accordance with Section 3.9.
skipping to change at page 21, line 5 skipping to change at page 21, 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 Block in Bundle ID
+======================================+====+ +==========================================+====+
| Primary Block | B1 | | Primary Block | B1 |
+--------------------------------------+----+ +------------------------------------------+----+
| BIB | B2 | | BIB | B2 |
| OP(integrity, targets=B1, B5, B6) | | | OP(bib-integrity, targets=B1, B5, B6) | |
+--------------------------------------+----+ +------------------------------------------+----+
| BCB | B3 | | BCB | B3 |
| OP(confidentiality, target=B4) | | | OP(bcb-confidentiality, target=B4) | |
+--------------------------------------+----+ +------------------------------------------+----+
| Extension Block (encrypted) | B4 | | Extension Block (encrypted) | B4 |
+--------------------------------------+----+ +------------------------------------------+----+
| Extension Block | B5 | | Extension Block | B5 |
+--------------------------------------+----+ +------------------------------------------+----+
| Payload Block | B6 | | 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 canonical form of the o An integrity signature applied to the canonical form of the
primary block (B1), the canonical form of the block-type-specific- primary block (B1), the canonical form of the block-type-specific-
data field of the second extension block (B5) and the canonical data field of the second extension block (B5) and the canonical
form of the payload block (B6). This is accomplished by a single form of the payload block (B6). This is accomplished by a single
skipping to change at page 22, line 11 skipping to change at page 22, 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 Block in Bundle ID
+======================================+====+ +==========================================+====+
| Primary Block | B1 | | Primary Block | B1 |
+--------------------------------------+----+ +------------------------------------------+----+
| BIB | B2 | | BIB | B2 |
| OP(integrity, targets=B1) | | | OP(bib-integrity, targets=B1) | |
+--------------------------------------+----+ +------------------------------------------+----+
| BIB (encrypted) | B7 | | BIB (encrypted) | B7 |
| OP(integrity, targets=B5, B6) | | | OP(bib-integrity, targets=B5, B6) | |
+--------------------------------------+----+ +------------------------------------------+----+
| BCB | B8 | | BCB | B8 |
| OP(confidentiality, target=B5,B6,B7) | | | OP(bcb-confidentiality,targets=B5,B6,B7) | |
+--------------------------------------+----+ +------------------------------------------+----+
| BCB | B3 | | BCB | B3 |
| OP(confidentiality, target=B4) | | | OP(bcb-confidentiality, target=B4) | |
+--------------------------------------+----+ +------------------------------------------+----+
| Extension Block (encrypted) | B4 | | Extension Block (encrypted) | B4 |
+--------------------------------------+----+ +------------------------------------------+----+
| Extension Block (encrypted) | B5 | | Extension Block (encrypted) | B5 |
+--------------------------------------+----+ +------------------------------------------+----+
| Payload Block (encrypted) | B6 | | 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 the block-type-specific- o Since the waypoint node wishes to encrypt the block-type-specific-
data field of blocks B5 and B6, it MUST also encrypt the block- data field of blocks B5 and B6, it MUST also encrypt the block-
type-specific-data field of the BIBs providing plain text type-specific-data field of the BIBs providing plain text
integrity over those blocks. However, BIB B2 could not be integrity over those blocks. However, BIB B2 could not be
skipping to change at page 36, line 9 skipping to change at page 36, line 9
Network operators must determine the number, type, and configuration Network operators must determine the number, type, and configuration
of security contexts in a system. Networks with rapidly changing of security contexts in a system. Networks with rapidly changing
configurations may define relatively few security contexts with each configurations may define relatively few security contexts with each
context customized with multiple parameters. For networks with more context customized with multiple parameters. For networks with more
stability, or an increased need for confidentiality, a larger number stability, or an increased need for confidentiality, a larger number
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 | | | | Type | | |
+---------+------------+--------------------------------------------+ +------------+------------+-----------------------------------------+
| 1 | Encrypted | AES-GCM-256 cipher suite with provided | | Key | Encrypted | AES-GCM-256 cipher suite with provided |
| | Key, IV | ephemeral key encrypted with a | | Exchange | Key, IV | ephemeral key encrypted with a |
| | | predetermined key encryption key and clear | | AES | | predetermined key encryption key and |
| | | text initialization vector. | | | | clear text initialization vector. |
| 2 | IV | AES-GCM-256 cipher suite with | | Pre-shared | IV | AES-GCM-256 cipher suite with |
| | | predetermined key and predetermined | | Key AES | | predetermined key and predetermined |
| | | key rotation policy. | | | | key rotation policy. |
| 3 | Nil | AES-GCM-256 cipher suite with all info | | Out of | None | AES-GCM-256 cipher suite with all info |
| | | predetermined. | | Band AES | | predetermined. |
+---------+------------+--------------------------------------------+ +------------+------------+-----------------------------------------+
Table 1 Table 1
9.3. Authorship 9.3. 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
therefore BPSec) will operate. Specifically, the delay and capacity therefore BPSec) will operate. Specifically, the delay and capacity
of delay-tolerant networks can vary substantially. Developers should of delay-tolerant networks can vary substantially. Developers should
consider these conditions to better describe the conditions when consider these conditions to better describe the conditions when
skipping to change at page 40, line 37 skipping to change at page 40, line 37
Negative security context identifiers are reserved for local/site- Negative security context identifiers are reserved for local/site-
specific uses. The use of 0 as a security context identifier is for specific uses. The use of 0 as a security context identifier is for
non-operational testing purposes only. non-operational testing purposes only.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
Version 7", draft-ietf-dtn-bpbis-26 (work in progress), Version 7", draft-ietf-dtn-bpbis-28 (work in progress),
July 2020. October 2020.
[I-D.ietf-dtn-bpsec-interop-sc] [I-D.ietf-dtn-bpsec-interop-sc]
Birrane, E., "BPSec Interoperability Security Contexts", Birrane, E., "BPSec Default Security Contexts", draft-
draft-ietf-dtn-bpsec-interop-sc-01 (work in progress), ietf-dtn-bpsec-interop-sc-02 (work in progress), November
February 2020. 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
 End of changes. 16 change blocks. 
85 lines changed or deleted 97 lines changed or added

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