draft-ietf-dtn-bpsec-10.txt   draft-ietf-dtn-bpsec-11.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: October 11, 2019 April 9, 2019 Expires: March 12, 2020 September 9, 2019
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-10 draft-ietf-dtn-bpsec-11
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.
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 October 11, 2019. This Internet-Draft will expire on March 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Supported Security Services . . . . . . . . . . . . . . . 3 1.1. Supported Security Services . . . . . . . . . . . . . . . 3
1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4 1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4
1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5 1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . 7 2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8
2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8
2.4. User-Defined Security Contexts . . . . . . . . . . . . . 8 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9
2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9
3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9
3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11
3.4. Target Identification . . . . . . . . . . . . . . . . . . 11 3.4. Target Identification . . . . . . . . . . . . . . . . . . 11
3.5. Block Representation . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . 18
3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . . . 21 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22
5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22
5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 22 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23
5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 22 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23
5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 23 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24
5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . 28 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29
8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 29 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30
8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 29 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 30
9. Security Context Considerations . . . . . . . . . . . . . . . 30 9. Security Context Considerations . . . . . . . . . . . . . . . 31
9.1. Identification and Configuration . . . . . . . . . . . . 30 9.1. Identification and Configuration . . . . . . . . . . . . 31
9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 31 9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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 5, line 16 skipping to change at page 5, line 17
This specification addresses neither the fitness of externally- This specification addresses neither the fitness of externally-
defined cryptographic methods nor the security of their defined cryptographic methods nor the security of their
implementation. Different networking conditions and operational implementation. Different networking conditions and operational
considerations require varying strengths of security mechanism such considerations require varying strengths of security mechanism such
that mandating a cipher suite in this specification may result in too that mandating a cipher suite in this specification may result in too
much security for some networks and too little security in others. much security for some networks and too little security in others.
It is expected that separate documents will be standardized to define It is expected that separate documents will be standardized to define
security contexts and cipher suites compatible with BPSec, to include security contexts and cipher suites compatible with BPSec, to include
those that should be used to assess interoperability and those fit those that should be used to assess interoperability and those fit
for operational use in various network scenarios. for operational use in various network scenarios. A sample security
context has been defined ([I-D.ietf-dtn-bpsec-interop-sc]) to support
interoperability testing and serve as an exemplar for how security
contexts should be defined for this specification.
This specification does not address the implementation of security This specification does not address the implementation of security
policy and does not provide a security policy for the BPSec. Similar policy and does not provide a security policy for the BPSec. Similar
to cipher suites, security policies are based on the nature and to cipher suites, security policies are based on the nature and
capabilities of individual networks and network operational concepts. capabilities of individual networks and network operational concepts.
This specification does provide policy considerations when building a This specification does provide policy considerations when building a
security policy. security policy.
With the exception of the Bundle Protocol, this specification does With the exception of the Bundle Protocol, this specification does
not address how to combine the BPSec security blocks with other not address how to combine the BPSec security blocks with other
skipping to change at page 6, line 18 skipping to change at page 6, line 23
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This section defines terminology either unique to the BPSec or This section defines terminology either unique to the BPSec or
otherwise necessary for understanding the concepts defined in this otherwise necessary for understanding the concepts defined in this
specification. specification.
o Bundle Destination - the node which receives a bundle and delivers
the payload of the bundle to an application. Also, the Node ID of
the BPA receiving the bundle. The bundle destination acts as the
security destination for every security target in every security
block in every bundle it receives.
o Bundle Source - the node which originates a bundle. Also, the o Bundle Source - the node which originates a bundle. Also, the
Node ID of the BPA originating the bundle. Node ID of the BPA originating the bundle.
o Cipher Suite - a set of one or more algorithms providing integrity o Cipher Suite - a set of one or more algorithms providing integrity
and confidentiality services. Cipher suites may define necessary and confidentiality services. Cipher suites may define necessary
parameters but do not provide values for those parameters. parameters but do not provide values for those parameters.
o Forwarder - any node that transmits a bundle in the DTN. Also, o Forwarder - any node that transmits a bundle in the DTN. Also,
the Node ID of the Bundle Protocol Agent (BPA) that sent the the Node ID of the Bundle Protocol Agent (BPA) that sent the
bundle on its most recent hop. bundle on its most recent hop.
skipping to change at page 6, line 42 skipping to change at page 7, line 5
o Path - the ordered sequence of nodes through which a bundle passes o Path - the ordered sequence of nodes through which a bundle passes
on its way from Source to Destination. The path is not on its way from Source to Destination. The path is not
necessarily known in advance by the bundle or any BPAs in the DTN. necessarily known in advance by the bundle or any BPAs in the DTN.
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 Destination - a bundle node that processes one or more
security blocks in a bundle. Also, the Node ID of that node.
o Security Operation - the application of a security service to a o Security Operation - the application of a security service to a
security target, notated as OP(security service, security target). security target, notated as OP(security service, security target).
For example, OP(confidentiality, payload). Every security For example, OP(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 security
service can only be applied to a security target once in a bundle. service can only be applied to a security target once in a bundle.
A security operation is implemented by a security block. A security operation is implemented by a security block.
o Security Service - the security features supported by this o Security Service - the security features supported by this
specification: either integrity or confidentiality. specification: either integrity or confidentiality.
skipping to change at page 11, line 9 skipping to change at page 11, line 24
block when all of the following conditions are true. block when all of the following conditions are true.
o The security operations apply the same security service. For o The security operations apply the same security service. For
example, they are all integrity operations or all confidentiality example, they are all integrity operations or all confidentiality
operations. operations.
o The security context parameters and key information for the o The security context parameters and key information for the
security operations are identical. security operations are identical.
o The security source for the security operations is the same. o The security source for the security operations is the same.
Meaning the set of operations are being added/removed by the same Meaning the set of operations are being added by the same node.
node.
o No security operations have the same security target, as that o No security operations have the same security target, as that
would violate the need for security operations to be unique. would violate the need for security operations to be unique.
o None of the security operations conflict with security operations o None of the security operations conflict with security operations
already present in the bundle. already present in the bundle.
When representing multiple security operations in a single security When representing multiple security operations in a single security
block, the information that is common across all operations is block, the information that is common across all operations is
represented once in the security block, and the information which is represented once in the security block, and the information which is
different (e.g., the security targets) are represented individually. different (e.g., the security targets) are represented individually.
When the security block is processed all security operations
represented by the security block MUST be applied/evaluated at that It is RECOMMENDED that if a node processes any security operation in
time. a security block that it process all security operations in the
security block. This allows security sources to assert that the set
of security operations in a security block are expected to be
processed by the same security destination. However, the
determination of whether a node actually is a security destination or
not is a matter of the policy of the node itself. In cases where a
receiving node determines that it is the security destination of only
a subset of the security operations in a security block, the node may
choose to only process that subset of security operations.
3.4. Target Identification 3.4. Target Identification
A security target is a block in the bundle to which a security A security target is a block in the bundle to which a security
service applies. This target must be uniquely and unambiguously service applies. This target must be uniquely and unambiguously
identifiable when processing a security block. The definition of the identifiable when processing a security block. The definition of the
extension block header from [I-D.ietf-dtn-bpbis] provides a "Block extension block header from [I-D.ietf-dtn-bpbis] provides a "Block
Number" field suitable for this purpose. Therefore, a security Number" field suitable for this purpose. Therefore, a security
target in a security block MUST be represented as the Block Number of target in a security block MUST be represented as the Block Number of
the target block. the target block.
skipping to change at page 12, line 40 skipping to change at page 13, line 16
Security Context Id: Security Context Id:
This field identifies the security context used to implement This field identifies the security context used to implement
the security service represented by this block and applied to the security service represented by this block and applied to
each security target. This field SHALL be represented by a each security target. This field SHALL be represented by a
CBOR unsigned integer. CBOR unsigned integer.
Security Context Flags: Security Context Flags:
This field identifies 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 security block. This field SHALL be represented as a CBOR
unsigned integer containing a bit field of 5 bits indicating unsigned integer whose contents shall be interpreted as a bit
the presence or absence of other security block fields, as field. Each bit in this bit field indicates the presence (bit
follows. set to 1) or absence (bit set to 0) of optional data in the
security block. The association of bits to security block data
Bit 1 (the most-significant bit, 0x10): reserved. is defined as follows.
Bit 2 (0x08): reserved.
Bit 3 (0x04): reserved.
Bit 4 (0x02): Security Source Present Flag.
Bit 5 (the least-significant bit, 0x01): Security Context Bit 1 (the least-significant bit, 0x01): Security Context
Parameters Present Flag. Parameters Present Flag.
Bit 2 (0x02): Security Source Present Flag.
In this field, a value of 1 indicates that the associated In this field, a value of 1 indicates that the associated
security block field MUST be included in the security block. A security block field MUST be included in the security block. A
value of 0 indicates that the associated security block field value of 0 indicates that the associated security block field
MUST NOT be in the security block. MUST NOT be in the security block.
Security Source (Optional): Security Source (Optional):
This field identifies the Endpoint that inserted the security This field identifies the Endpoint that inserted the security
block in the bundle. If the security source field is not block in the bundle. If the security source field is not
present then the source MUST be inferred from other present then the source MUST be inferred from other
information, such as the bundle source, previous hop, or other information, such as the bundle source, previous hop, or other
skipping to change at page 16, line 32 skipping to change at page 16, line 47
reference the payload block, a non-security extension block, or a reference the payload block, a non-security extension block, or a
BIB. A BCB MUST NOT include another BCB as a security target. A BIB. A BCB MUST NOT include another BCB as a security target. A
BCB MUST NOT target the primary block. BCB MUST NOT target the primary block.
The Security Context Id MUST utilize a confidentiality cipher that The Security Context Id MUST utilize a confidentiality cipher that
provides authenticated encryption with associated data (AEAD). provides authenticated encryption with associated data (AEAD).
Additional information created by a cipher suite (such as Additional information created by a cipher suite (such as
additional authenticated data) can be placed either in a security additional authenticated data) can be placed either in a security
result field or in the generated cipher-text. The determination result field or in the generated cipher-text. The determination
of where to place these data is a function of the cipher suite of where to place these data is a function of the cipher suite and
used. security context used.
An EID-reference to the security source MAY be present. If this An EID-reference to the security source MAY be present. If this
field is not present, then the security source of the block SHOULD field is not present, then the security source of the block SHOULD
be inferred according to security policy and MAY default to the be 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
the key information described in Section 3.10. the key information described in Section 3.10.
The BCB modifies the contents of its security target(s). When a BCB The BCB modifies the contents of its security target(s). When a BCB
is applied, the security target body data are encrypted "in-place". is applied, the security target body data are encrypted "in-place".
Following encryption, the security target Block Type Specific Data Following encryption, the security target Block Type Specific Data
skipping to change at page 17, line 35 skipping to change at page 17, line 50
o When adding a BCB to a bundle, if some (or all) of the security o When adding a BCB to a bundle, if some (or all) of the security
targets of the BCB also match all of the security targets of an targets of the BCB also match all of the security targets of an
existing BIB, then the existing BIB MUST also be encrypted. This existing BIB, then the existing BIB MUST also be encrypted. This
can be accomplished by either adding a new BCB that targets the can be accomplished by either adding a new BCB that targets the
existing BIB, or by adding the BIB to the list of security targets existing BIB, or by adding the BIB to the list of security targets
for the BCB. Deciding which way to represent this situation is a for the BCB. Deciding which way to represent this situation is a
matter of security policy. matter of security policy.
o When adding a BCB to a bundle, if some (or all) of the security o When adding a BCB to a bundle, if some (or all) of the security
targets of the BCB match some (but not all) of the security targets of the BCB match some (but not all) of the security
targets of a BIB, then a new BIB MUST be created and all entries targets of a BIB then that BIB MUST be altered in the following
relating to those BCB security targets MUST be moved from the way. Any security results in the BIB associated with the BCB
original BIB to the newly created BIB. The newly created BIB MUST security targets MUST be removed from the BIB and placed in a new
then be encrypted. This can be accomplished by either adding a BIB. This newly created BIB MUST then be encrypted. The
encryption of the new BIB can be accomplished by either adding a
new BCB that targets the new BIB, or by adding the new BIB to the new BCB that targets the new BIB, or by adding the new BIB to the
list of security targets for the BCB. Deciding which way to list of security targets for the BCB. Deciding which way to
represent this situation is a matter of security policy. represent this situation is a matter of security policy.
o A BIB MUST NOT be added for a security target that is already the o A BIB MUST NOT be added for a security target that is already the
security target of a BCB. In this instance, the BCB is already security target of a BCB. In this instance, the BCB is already
providing authentication and integrity of the security target and providing authentication and integrity of the security target and
the BIB would be redundant, insecure, and cause ambiguity in block the BIB would be redundant, insecure, and cause ambiguity in block
processing order. processing order.
skipping to change at page 18, line 31 skipping to change at page 18, line 47
NOTE: Since any cipher suite used with a BCB MUST be an AEAD cipher NOTE: Since any cipher suite used with a BCB MUST be an AEAD cipher
suite, it is inefficient and possibly insecure for a single security suite, it is inefficient and possibly insecure for a single security
source to add both a BIB and a BCB for the same security target. In source to add both a BIB and a BCB for the same security target. In
cases where a security source wishes to calculate both a plain-text cases where a security source wishes to calculate both a plain-text
integrity mechanism and encrypt a security target, a BCB with a integrity mechanism and encrypt a security target, a BCB with a
cipher suite that generates such signatures as additional security cipher suite that generates such signatures as additional security
results SHOULD be used instead. results SHOULD be used instead.
3.10. Parameter and Result Identification 3.10. Parameter and Result Identification
Security context parameters and results each represent multiple Each security context MUST define its own context parameters and
distinct pieces of information in a security block. Each piece of security results. Each defined parameter and result is represented
information is assigned an identifier and a CBOR encoding. as the tuple of an identifier and a value. Identifiers are always
Identifiers MUST be unique for a given cipher suite but do not need represented as a CBOR unsigned integer. The CBOR encoding of values
to be unique across all cipher suites. Therefore, parameter Ids and is as defined by the security context specification.
result Ids are specified in the context of a cipher suite definition.
Individual BPSec security context identifiers SHOULD use existing
registries of identifiers and CBOR encodings, such as those defined
in [RFC8152], whenever possible. Contexts SHOULD define their own
identifiers and CBOR encodings when necessary.
Parameters and results are represented using CBOR, and any Identifiers MUST be unique for a given security context but do not
identification of a new parameter or result must include how the need to be unique amongst all security contexts.
value will be represented using the CBOR specification. Ids
themselves are always represented as a CBOR unsigned integer.
3.11. BSP Block Examples 3.11. BSP Block Examples
This section provides two examples of BPSec blocks applied to a This section provides two examples of BPSec blocks applied to a
bundle. In the first example, a single node adds several security bundle. In the first example, a single node adds several security
operations to a bundle. In the second example, a waypoint node operations to a bundle. In the second example, a waypoint node
received the bundle created in the first example and adds additional received the bundle created in the first example and adds additional
security operations. In both examples, the first column represents security operations. In both examples, the first column represents
blocks within a bundle and the second column represents the Block blocks within a bundle and the second column represents the Block
Number for the block, using the terminology B1...Bn for the purpose Number for the block, using the terminology B1...Bn for the purpose
skipping to change at page 22, line 10 skipping to change at page 22, line 41
Fields from plain-text to cipher-text. Fields from plain-text to cipher-text.
o Reserved flags MUST NOT be included in any canonicalization as it o Reserved flags MUST NOT be included in any canonicalization as it
is not known if those flags will change in transit. is not known if those flags will change in transit.
These canonicalization algorithms assume that Endpoint IDs do not These canonicalization algorithms assume that Endpoint IDs do not
change from the time at which a security source adds a security block 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 to a bundle and the time at which a node processes that security
block. block.
Cipher suites MAY define their own canonicalization algorithms and Cipher suites and security contexts MAY define their own
require the use of those algorithms over the ones provided in this canonicalization algorithms and require the use of those algorithms
specification. In the event of conflicting canonicalization over the ones provided in this specification. In the event of
algorithms, cipher suite algorithms take precedence over this conflicting canonicalization algorithms, those algorithms take
specification. precedence over this specification.
5. Security Processing 5. Security Processing
This section describes the security aspects of bundle processing. This section describes the security aspects of bundle processing.
5.1. Bundles Received from Other Nodes 5.1. Bundles Received from Other Nodes
Security blocks must be processed in a specific order when received Security blocks must be processed in a specific order when received
by a security-aware node. The processing order is as follows. by a security-aware node. The processing order is as follows.
o When BIBs and BCBs share a security target, BCBs MUST be evaluated o When BIBs and BCBs share a security target, BCBs MUST be evaluated
first and BIBs second. first and BIBs second.
5.1.1. Receiving BCBs 5.1.1. Receiving BCBs
If a received bundle contains a BCB, the receiving node MUST If a received bundle contains a BCB, the receiving node MUST
determine whether it has the responsibility of decrypting the BCB determine whether it is the security destination for any of the
security target and removing the BCB prior to delivering data to an security operations in the BCB. If so, the node MUST process those
application at the node or forwarding the bundle. operations and remove any operation-specific information from the BCB
prior to delivering data to an application at the node or forwarding
the bundle. If processing a security operation fails, the target
SHALL be processed according to the security policy. A bundle status
report indicating the failure MAY be generated. When all security
operations for a BCB have been removed from the BCB, the BCB MUST be
removed from the bundle.
If the receiving node is the destination of the bundle, the node MUST If the receiving node is the destination of the bundle, the node MUST
decrypt any BCBs remaining in the bundle. If the receiving node is decrypt any BCBs remaining in the bundle. If the receiving node is
not the destination of the bundle, the node MUST decrypt the BCB if not the destination of the bundle, the node MUST process the BCB if
directed to do so as a matter of security policy. directed to do so as a matter of security policy.
If the security policy of a security-aware node specifies that a If the security policy of a security-aware node specifies that a
bundle should have applied confidentiality to a specific security bundle should have applied confidentiality to a specific security
target and no such BCB is present in the bundle, then the node MUST target and no such BCB is present in the bundle, then the node MUST
process this security target in accordance with the security policy. process this security target in accordance with the security policy.
This may involve removing the security target from the bundle. If This may involve removing the security target from the bundle. If
the removed security target is the payload block, the bundle MUST be the removed security target is the payload block, the bundle MUST be
discarded. discarded.
skipping to change at page 23, line 13 skipping to change at page 24, line 5
and all security blocks associated with that target MUST be discarded and all security blocks associated with that target MUST be discarded
and processed no further. In both cases, requested status reports and processed no further. In both cases, requested status reports
(see [I-D.ietf-dtn-bpbis]) MAY be generated to reflect bundle or (see [I-D.ietf-dtn-bpbis]) MAY be generated to reflect bundle or
block deletion. block deletion.
When a BCB is decrypted, the recovered plain-text MUST replace the When a BCB is decrypted, the recovered plain-text MUST replace the
cipher-text in the security target Block Type Specific Data Fields. cipher-text in the security target Block Type Specific Data Fields.
If the Block Data Length field was modified at the time of encryption If the Block Data Length field was modified at the time of encryption
it MUST be updated to reflect the decrypted block length. it MUST be updated to reflect the decrypted block length.
If a BCB contains multiple security targets, all security targets If a BCB contains multiple security operations, each operation
MUST be processed when the BCB is processed. Errors and other processed by the node MUST be be treated as if the security operation
processing steps SHALL be made as if each security target had been has been represented by a single BCB with a single security
represented by an individual BCB with a single security target. operation.
5.1.2. Receiving BIBs 5.1.2. Receiving BIBs
If a received bundle contains a BIB, the receiving node MUST If a received bundle contains a BIB, the receiving node MUST
determine whether it has the final responsibility of verifying the determine whether it is the security destination for any of the
BIB security target and removing it prior to delivering data to an security operations in the BIB. If so, the node MUST process those
application at the node or forwarding the bundle. If a BIB check operations and remove any operation-specific information from the BIB
fails, the security target has failed to authenticate and the prior to delivering data to an application at the node or forwarding
security target SHALL be processed according to the security policy. the bundle. If processing a security operation fails, the target
A bundle status report indicating the failure MAY be generated. SHALL be processed according to the security policy. A bundle status
Otherwise, if the BIB verifies, the security target is ready to be report indicating the failure MAY be generated. When all security
processed for delivery. operations for a BIB have been removed from the BIB, the BIB MUST be
removed from the bundle.
A BIB MUST NOT be processed if the security target of the BIB is also A BIB MUST NOT be processed if the security target of the BIB is also
the security target of a BCB in the bundle. Given the order of the security target of a BCB in the bundle. Given the order of
operations mandated by this specification, when both a BIB and a BCB operations mandated by this specification, when both a BIB and a BCB
share a security target, it means that the security target must have share a security target, it means that the security target must have
been encrypted after it was integrity signed and, therefore, the BIB been encrypted after it was integrity signed and, therefore, the BIB
cannot be verified until the security target has been decrypted by cannot be verified until the security target has been decrypted by
processing the BCB. processing the BCB.
If the security policy of a security-aware node specifies that a If the security policy of a security-aware node specifies that a
bundle should have applied integrity to a specific security target bundle should have applied integrity to a specific security target
and no such BIB is present in the bundle, then the node MUST process and no such BIB is present in the bundle, then the node MUST process
this security target in accordance with the security policy. This this security target in accordance with the security policy. This
may involve removing the security target from the bundle. If the may involve removing the security target from the bundle. If the
removed security target is the payload or primary block, the bundle removed security target is the payload or primary block, the bundle
MAY be discarded. This action can occur at any node that has the MAY be discarded. This action can occur at any node that has the
ability to verify an integrity signature, not just the bundle ability to verify an integrity signature, not just the bundle
destination. destination.
If a receiving node does not have the final responsibility of If a receiving node is not the security destination of a security
verifying the BIB it MAY attempt to verify the BIB to prevent the operation in a BIB it MAY attempt to verify the security operation
needless forwarding of corrupt data. If the check fails, the node anyway to prevent forwarding corrupt data. If the verification
SHALL process the security target in accordance to local security fails, the node SHALL process the security target in accordance to
policy. It is RECOMMENDED that if a payload integrity check fails at local security policy. It is RECOMMENDED that if a payload integrity
a waypoint that it is processed in the same way as if the check fails check fails at a waypoint that it is processed in the same way as if
at the destination. If the check passes, the node MUST NOT remove the check fails at the bundle destination. If the check passes, the
the BIB prior to forwarding. node MUST NOT remove the security operation from the BIB prior to
forwarding.
If a BIB contains multiple security targets, all security targets If a BIB contains multiple security operations, each operation
MUST be processed if the BIB is processed by the Node. Errors and processed by the node MUST be be treated as if the security operation
other processing steps SHALL be made as if each security target had has been represented by a single BIB with a single security
been represented by an individual BIB with a single security target. operation.
5.2. Bundle Fragmentation and Reassembly 5.2. Bundle Fragmentation and Reassembly
If it is necessary for a node to fragment a bundle payload, and If it is necessary for a node to fragment a bundle payload, and
security services have been applied to that bundle, the fragmentation security services have been applied to that bundle, the fragmentation
rules described in [I-D.ietf-dtn-bpbis] MUST be followed. As defined rules described in [I-D.ietf-dtn-bpbis] MUST be followed. As defined
there and summarized here for completeness, only the payload block there and summarized here for completeness, only the payload block
can be fragmented; security blocks, like all extension blocks, can can be fragmented; security blocks, like all extension blocks, can
never be fragmented. never be fragmented.
skipping to change at page 33, line 24 skipping to change at page 34, line 16
and configuration associated with blocks SHOULD be included in any and configuration associated with blocks SHOULD be included in any
OSB definition. OSB definition.
NOTE: The burden of showing compliance with processing rules is NOTE: The burden of showing compliance with processing rules is
placed upon the standards defining new security blocks and the placed upon the standards defining new security blocks and the
identification of such blocks shall not, alone, require maintenance identification of such blocks shall not, alone, require maintenance
of this specification. of this specification.
11. IANA Considerations 11. IANA Considerations
A registry of security context identifiers will be required. This specification includes fields requiring registries managed by
IANA.
11.1. Bundle Block Types 11.1. Bundle Block Types
This specification allocates two block types from the existing This specification allocates two block types from the existing
"Bundle Block Types" registry defined in [RFC6255]. "Bundle Block Types" registry defined in [I-D.ietf-dtn-bpbis].
Additional Entries for the Bundle Block-Type Codes Registry: Additional Entries for the Bundle Block-Type Codes Registry:
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
| TBD | Block Integrity Block | This document | | 2 | Block Integrity Block | This document |
| TBD | Block Confidentiality Block | This document | | 3 | Block Confidentiality Block | This document |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
Table 2 Table 2
11.2. Security Context Identifiers
BPSec has a Security Context Identifier field () for which IANA is
requested to create and maintain a new registry named "BPSec Security
Context Identifiers". Initial values for this registry are given
below.
The registration policy for this registry is: Specification Required.
The value range is: unsigned 16-bit integer.
BPSec Security Context Identifier Registry
+-------+--------------------+---------------------------------+
| Value | Description | Reference |
+-------+--------------------+---------------------------------+
| 0 | Reserved | This document |
| 1 | BIB-HMAC256-SHA256 | [I-D.ietf-dtn-bpsec-interop-sc] |
| 2 | BCB-AES-GCM-256 | [I-D.ietf-dtn-bpsec-interop-sc] |
+-------+--------------------+---------------------------------+
Table 3
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-11 (work in progress), Version 7", draft-ietf-dtn-bpbis-14 (work in progress),
May 2018. August 2019.
[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>.
[RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol
IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May
2011, <https://www.rfc-editor.org/info/rfc6255>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
12.2. Informative References 12.2. Informative References
[I-D.birrane-dtn-sbsp] [I-D.birrane-dtn-sbsp]
Birrane, E., Pierce-Mayer, J., and D. Iannicca, Birrane, E., Pierce-Mayer, J., and D. Iannicca,
"Streamlined Bundle Security Protocol Specification", "Streamlined Bundle Security Protocol Specification",
draft-birrane-dtn-sbsp-01 (work in progress), October draft-birrane-dtn-sbsp-01 (work in progress), October
2015. 2015.
[I-D.ietf-dtn-bpsec-interop-sc]
Birrane, E., "BPSec Interoperability Security Contexts",
draft-ietf-dtn-bpsec-interop-sc-00 (work in progress),
March 2019.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>. April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257, "Bundle Security Protocol Specification", RFC 6257,
DOI 10.17487/RFC6257, May 2011, DOI 10.17487/RFC6257, May 2011,
<https://www.rfc-editor.org/info/rfc6257>. <https://www.rfc-editor.org/info/rfc6257>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
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
 End of changes. 38 change blocks. 
120 lines changed or deleted 157 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/