draft-ietf-dtn-bpsec-07.txt   draft-ietf-dtn-bpsec-08.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: January 2, 2019 July 1, 2018 Expires: April 25, 2019 October 22, 2018
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-07 draft-ietf-dtn-bpsec-08
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 January 2, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 11 skipping to change at page 2, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 7
2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8
2.4. User-Selected Cipher Suites . . . . . . . . . . . . . . . 8 2.4. User-Selected Cipher Suites . . . . . . . . . . . . . . . 8
2.5. Deterministic Processing . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 10
3.4. Target Identification . . . . . . . . . . . . . . . . . . 11 3.4. Target Identification . . . . . . . . . . . . . . . . . . 11
3.5. Block Representation . . . . . . . . . . . . . . . . . . 11 3.5. Block Representation . . . . . . . . . . . . . . . . . . 11
3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 11 3.6. Security Association Block . . . . . . . . . . . . . . . 12
3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 14 3.7. Abstract Security Block . . . . . . . . . . . . . . . . . 14
3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 15 3.8. Block Integrity Block . . . . . . . . . . . . . . . . . . 17
3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 16 3.9. Block Confidentiality Block . . . . . . . . . . . . . . . 18
3.10. Cipher Suite Parameter and Result Identification . . . . 18 3.10. Block Interactions . . . . . . . . . . . . . . . . . . . 19
3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 18 3.11. SA Parameters and Result Identification . . . . . . . . . 20
3.11.1. Example 1: Constructing a Bundle with Security . . . 18 3.12. BSP Block Examples . . . . . . . . . . . . . . . . . . . 21
3.11.2. Example 2: Adding More Security At A New Node . . . 19 3.12.1. Example 1: Constructing a Bundle with Security . . . 21
4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 21 3.12.2. Example 2: Adding More Security At A New Node . . . 22
5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 22 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24
5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 22 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 25
5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 23 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 25
5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 24 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 26
6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 27
7. Security Policy Considerations . . . . . . . . . . . . . . . 24 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Policy Considerations . . . . . . . . . . . . . . . 27
8.1. Attacker Capabilities and Objectives . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 27 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 29
8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 27 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 30
8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 28 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 30
8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 29 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 31
8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 29 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 32
9. Cipher Suite Authorship Considerations . . . . . . . . . . . 30 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 32
10. Defining Other Security Blocks . . . . . . . . . . . . . . . 31 9. Cipher Suite Authorship Considerations . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 34
11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 32 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 37
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 5, line 42 skipping to change at page 5, line 44
"Delay-Tolerant Networking Architecture" [RFC4838] defines the "Delay-Tolerant Networking Architecture" [RFC4838] defines the
architecture for DTNs and identifies certain security assumptions architecture for DTNs and identifies certain security assumptions
made by existing Internet protocols that are not valid in a DTN. made by existing Internet protocols that are not valid in a DTN.
The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and
processing of bundles, defines the extension block format used to processing of bundles, defines the extension block format used to
represent BPSec security blocks, and defines the canonicalization represent BPSec security blocks, and defines the canonicalization
algorithms used by this specification. algorithms used by this specification.
The Bundle Security Protocol [RFC6257] and Streamlined Bundle The Bundle Security Protocol [RFC6257] and Streamlined Bundle
Security Protocol [I-D.birrane-dtn-sbsp] documents introduced the Security Protocol [I-D.birrane-dtn-sbsp] documents introduced the
concepts of using BP extension blocks for security services in a DTN. concepts of using BP extension blocks for security services in a DTN.
The BPSec is a continuation and refinement of these documents. The BPSec is a continuation and refinement of these documents.
1.4. Terminology 1.4. Terminology
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].
skipping to change at page 9, line 14 skipping to change at page 9, line 23
are processed must be deterministic. All nodes must impose this same are processed must be deterministic. All nodes must impose this same
deterministic processing order for all security blocks. This deterministic processing order for all security blocks. This
specification provides determinism in the application and evaluation specification provides determinism in the application and evaluation
of security services, even when doing so results in a loss of of security services, even when doing so results in a loss of
flexibility. flexibility.
3. Security Blocks 3. Security Blocks
3.1. Block Definitions 3.1. Block Definitions
This specification defines two types of security block: the Block This specification defines three types of security block: the
Integrity Block (BIB) and the Block Confidentiality Block (BCB). Security Association Block (SAB), the Block Integrity Block (BIB) and
the Block Confidentiality Block (BCB).
The SAB is used to define security associations between two
messaging endpoints. In this sense, they are similar to security
associations used in other security protocols such as IPSec, with
the exception that these associations may be pre-negotiated as a
matter of policy, parameterized as part of their definition, or
otherwise made fit for use in a challenged networking scenario.
The BIB is used to ensure the integrity of its plain-text security The BIB is used to ensure the integrity of its plain-text security
target(s). The integrity information in the BIB MAY be verified target(s). The integrity information in the BIB MAY be verified
by any node along the bundle path from the BIB security source to by any node along the bundle path from the BIB security source to
the bundle destination. Security-aware waypoints add or remove the bundle destination. Security-aware waypoints add or remove
BIBs from bundles in accordance with their security policy. BIBs BIBs from bundles in accordance with their security policy. BIBs
are never used to sign the cipher-text provided by a BCB. are never used to sign the cipher-text provided by a BCB.
The BCB indicates that the security target(s) have been encrypted The BCB indicates that the security target(s) have been encrypted
at the BCB security source in order to protect their content while at the BCB security source in order to protect their content while
skipping to change at page 9, line 49 skipping to change at page 10, line 23
block MUST NOT be added. It is important to note that any cipher- block MUST NOT be added. It is important to note that any cipher-
text integrity mechanism supplied by the BCB is considered part of text integrity mechanism supplied by the BCB is considered part of
the confidentiality service and, therefore, unique from the plain- the confidentiality service and, therefore, unique from the plain-
text integrity service provided by the BIB. text integrity service provided by the BIB.
If multiple security blocks representing the same security operation If multiple security blocks representing the same security operation
were allowed in a bundle at the same time, there would exist were allowed in a bundle at the same time, there would exist
ambiguity regarding block processing order and the property of ambiguity regarding block processing order and the property of
deterministic processing blocks would be lost. deterministic processing blocks would be lost.
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(integrity,
payload) and OP(integrity, payload) are redundant and MUST NOT payload) and OP(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(integrity,
payload) and OP(integrity, extension_block_1) are not redundant payload) and OP(integrity, extension_block_1) are not redundant
and both may be present in the same bundle at the same time. and both may be present in the same bundle at the same time.
Similarly, the two operations OP(integrity, extension_block_1) and Similarly, the two operations OP(integrity, extension_block_1) and
OP(integrity,extension_block_2) are also not redundant and may OP(integrity,extension_block_2) are also not redundant and may
both be present in the bundle at the same time. both be present in the bundle at the same time.
o Different Services on same block: The two operations o Different Services on same block: The two operations OP(integrity,
OP(integrity,payload) and OP(confidentiality, payload) are not payload) and OP(confidentiality, payload) are not inherently
inherently redundant and may both be present in the bundle at the redundant and may both be present in the bundle at the same time,
same time, pursuant to other processing rules in this pursuant to other processing rules in this specification.
specification.
3.3. Target Multiplicity 3.3. Target Multiplicity
Under special circumstances, a single security block MAY represent Under special circumstances, a single security block MAY represent
multiple security operations as a way of reducing the overall number multiple security operations as a way of reducing the overall number
of security blocks present in a bundle. In these circumstances, of security blocks present in a bundle. In these circumstances,
reducing the number of security blocks in the bundle reduces the reducing the number of security blocks in the bundle reduces the
amount of redundant information in the bundle. amount of redundant information in the bundle.
A set of security operations can be represented by a single security A set of security operations can be represented by a single security
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 cipher suite parameters and key information for the security o The security association parameters and key information for the
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/removed 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.
skipping to change at page 11, line 32 skipping to change at page 12, line 4
in [I-D.ietf-dtn-bpbis]. That is, each security block is comprised in [I-D.ietf-dtn-bpbis]. That is, each security block is comprised
of the following elements: of the following elements:
o Block Type Code o Block Type Code
o Block Number o Block Number
o Block Processing Control Flags o Block Processing Control Flags
o CRC Type and CRC Field (if present) o CRC Type and CRC Field (if present)
o Block Data Length o Block Data Length
o Block Type Specific Data Fields o Block Type Specific Data Fields
Security-specific information for a security block is captured in the Security-specific information for a security block is captured in the
"Block Type Specific Data Fields". "Block Type Specific Data Fields".
3.6. Abstract Security Block 3.6. Security Association Block
The SAB defines a security association (SA) between bundle messaging
endpoints. This association captures the set of parameterized cipher
suite information, key information, and other annotative information
necessary to configure security services in the network.
In deployments where data communications are challenged, the SAB
block may be omitted in favor of negotiating SAs using out-of-band
mechanisms.
The Block Type Code of an SAB is as specified in Section 11.1.
The Block number, Block Processing Control Flags, CRC Type and CRC
Field, and Block Data Length may be set in any way that conforms with
security policy and in compliance with [I-D.ietf-dtn-bpbis].
The Block Type Specific Data Fields of the SAB MUST be encoded as a
CBOR array, with each element of the array defining a unique SA.
An individual security association (SA) MUST be encoded as a CBOR
array comprising the following fields, listed in the order in which
they must appear.
Security Association Id:
This field identifies the identifier for the SA. This field
SHALL be represented by a CBOR unsigned integer.
Security Association Flags:
This field identifies which optional fields are present in the
security block. This field SHALL be represented as a CBOR
unsigned integer containing a bit field of 5 bits indicating
the presence or absence of other fields, as follows.
Bit 1 (the most-significant bit, 0x10): EID Scope Flag.
Bit 2 (0x08): Block Type Scope Flag.
Bit 3 (0x04): Cipher Suite Id Present Flag.
Bit 4 (0x02): Security Source Present Flag.
Bit 5 (the least-significant bit, 0x01): Security Association
Parameters Present Flag.
In this field, a value of 1 indicates that the associated
security block field MUST be included in the security block. A
value of 0 indicates that the associated security block field
MUST NOT be in the security block.
EID Scope (Optional Field):
This field identifies the message destinations (as a series of
Endpoints) for which this SA should be applied. If this field
is not present, the SA may be applied to any message endpoints
or may be filtered in some other way in accordance with
security policy. This field SHALL be represented by a CBOR
array with each element containing an EID encoded in accordance
with [I-D.ietf-dtn-bpbis] rules for representing Endpoint
Identifiers (EIDs).
Block Type Scope (Optional Field):
This field identifies the block types for which this SA should
be applied. If this field is not present, the SA may be
applied to any block type or may be filtered in some other way
in accordance with security policy. This field SHALL be
represented by a CBOR array with each element containing a
block type encoded in accordance with [I-D.ietf-dtn-bpbis]
rules for representing block types.
Cipher Suite Id (Optional Field):
This field identifies the cipher suite used by this SA. If
this field is not present, the cipher suite associated with
this SA MUST be known through some alternative mechanisms, such
as local security policy or out-of-band configuration. The
cipher suite Id SHALL be presented by a CBOR unsigned integer.
Security Source (Optional Field):
This field identifies the Endpoint that inserted the security
block in the bundle. If the security source field is not
present then the source MUST be inferred from other
information, such as the bundle source, previous hop, or other
values defined by security policy. This field SHALL be
represented by a CBOR array in accordance with
[I-D.ietf-dtn-bpbis] rules for representing Endpoint
Identifiers (EIDs).
Security Association Parameters (Optional Field):
This field captures one or more security association parameters
that should be provided to security-aware nodes when processing
the security service described by this security block. This
field SHALL be represented by a CBOR array. Each entry in this
array is a single SA parameter. A single SA parameter SHALL
also be represented as a CBOR array comprising a 2-tuple of the
id and value of the parameter, as follows.
* Parameter Id. This field identifies which SA parameter is
being specified. This field SHALL be represented as a CBOR
unsigned integer. Parameter ids are selected as described
in Section 3.11.
* Parameter Value. This field captures the value associated
with this parameter. This field SHALL be represented by the
applicable CBOR representation of the parameter, in
accordance with Section 3.11.
The logical layout of the security association parameters array
is illustrated in Figure 1.
+----------------+----------------+ +----------------+
| Parameter 1 | Parameter 2 | ... | Parameter N |
+------+---------+------+---------+ +------+---------+
| Id | Value | Id | Value | | Id | Value |
+------+---------+------+---------+ +------+---------+
Figure 1: Security Association Parameters
Notes:
o It is RECOMMENDED that security association designers carefully
consider the effect of setting flags that either discard the block
or delete the bundle in the event that this block cannot be
processed.
3.7. Abstract Security Block
The structure of the security-specific portions of a security block The structure of the security-specific portions of a security block
is identical for both the BIB and BCB Block Types. Therefore, this is identical for both the BIB and BCB Block Types. Therefore, this
section defines an Abstract Security Block (ASB) data structure and section defines an Abstract Security Block (ASB) data structure and
discusses the definition, processing, and other constraints for using discusses the definition, processing, and other constraints for using
this structure. An ASB is never directly instantiated within a this structure. An ASB is never directly instantiated within a
bundle, it is only a mechanism for discussing the common aspects of bundle, it is only a mechanism for discussing the common aspects of
BIB and BCB security blocks. BIB and BCB security blocks.
The fields of the ASB SHALL be as follows, listed in the order in The fields of the ASB SHALL be as follows, listed in the order in
skipping to change at page 12, line 16 skipping to change at page 15, line 15
This field identifies the block(s) targeted by the security This field identifies the block(s) targeted by the security
operation(s) represented by this security block. Each target operation(s) represented by this security block. Each target
block is represented by its unique Block Number. This field block is represented by its unique Block Number. This field
SHALL be represented by a CBOR array of data items. Each SHALL be represented by a CBOR array of data items. Each
target within this CBOR array SHALL be represented by a CBOR target within this CBOR array SHALL be represented by a CBOR
unsigned integer. This array MUST have at least 1 entry and unsigned integer. This array MUST have at least 1 entry and
each entry MUST represent the Block Number of a block that each entry MUST represent the Block Number of a block that
exists in the bundle. There MUST NOT be duplicate entries in exists in the bundle. There MUST NOT be duplicate entries in
this array. this array.
Cipher Suite Id: Security Association Id:
This field identifies the cipher suite used to implement the This field identifies the cipher suite used to implement the
security service represented by this block and applied to each security service represented by this block and applied to each
security target. This field SHALL be represented by a CBOR security target. This field SHALL be represented by a CBOR
unsigned integer. unsigned integer.
Cipher Suite Flags: Security Association 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 containing a bit field of 5 bits indicating
the presence or absence of other security block fields, as the presence or absence of other security block fields, as
follows. follows.
Bit 1 (the most-significant bit, 0x10): reserved. Bit 1 (the most-significant bit, 0x10): reserved.
Bit 2 (0x08): reserved. Bit 2 (0x08): reserved.
Bit 3 (0x04): reserved. Bit 3 (0x04): reserved.
Bit 4 (0x02): Security Source Present Flag. Bit 4 (0x02): Security Source Present Flag.
Bit 5 (the least-significant bit, 0x01): Cipher Suite Bit 5 (the least-significant bit, 0x01): reserved.
Parameters 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 Field): Security Source (Optional Field):
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
skipping to change at page 13, line 4 skipping to change at page 15, line 50
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 Field): Security Source (Optional Field):
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
values defined by security policy. This field SHALL be values defined by security policy. This field SHALL be
represented by a CBOR array in accordance with represented by a CBOR array in accordance with
[I-D.ietf-dtn-bpbis] rules for representing Endpoint [I-D.ietf-dtn-bpbis] rules for representing Endpoint
Identifiers (EIDs). Identifiers (EIDs).
Cipher Suite Parameters (Optional Field):
This field captures one or more cipher suite parameters that
should be provided to security-aware nodes when processing the
security service described by this security block. This field
SHALL be represented by a CBOR array. Each entry in this array
is a single cipher suite parameter. A single cipher suite
parameter SHALL also be represented as a CBOR array comprising
a 2-tuple of the id and value of the parameter, as follows.
* Parameter Id. This field identifies which cipher suite
parameter is being specified. This field SHALL be
represented as a CBOR unsigned integer. Parameter ids are
selected as described in Section 3.10.
* Parameter Value. This field captures the value associated
with this parameter. This field SHALL be represented by the
applicable CBOR representation of the parameter, in
accordance with Section 3.10.
The logical layout of the cipher suite parameters array is
illustrated in Figure 1.
+----------------+----------------+ +----------------+
| Parameter 1 | Parameter 2 | ... | Parameter N |
+------+---------+------+---------+ +------+---------+
| Id | Value | Id | Value | | Id | Value |
+------+---------+------+---------+ +------+---------+
Figure 1: Cipher Suite Parameters
Security Results: 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
array corresponds to the first entry in the Security Targets array corresponds to the first entry in the Security Targets
field of the security block, and so on. There MUST be one field of the security block, and so on. There MUST be one
skipping to change at page 14, line 13 skipping to change at page 16, line 29
a CBOR array of individual results. An individual result is a CBOR array of individual results. An individual result is
represented as a 2-tuple of a result id and a result value, represented as a 2-tuple of a result id and a result value,
defined as follows. defined as follows.
* Result Id. This field identifies which security result is * Result Id. This field identifies which security result is
being specified. Some security results capture the primary being specified. Some security results capture the primary
output of a cipher suite. Other security results contain output of a cipher suite. Other security results contain
additional annotative information from cipher suite additional annotative information from cipher suite
processing. This field SHALL be represented as a CBOR processing. This field SHALL be represented as a CBOR
unsigned integer. Security result ids will be as specified unsigned integer. Security result ids will be as specified
in Section 3.10. in Section 3.11.
* 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.11.
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 | | Target 1 | | Target N |
+------------+----+------------+ +------------------------------+ +------------+----+------------+ +------------------------------+
| Result 1 | | Result M | ... | Result 1 | | Result K | | Result 1 | | Result M | ... | Result 1 | | Result K |
+----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+
| Id | Value | | Id | Value | | Id | Value | | Id | Value | | Id | Value | | Id | Value | | Id | Value | | Id | Value |
+----+-------+ +----+-------+ +----+-------+ +----+-------+ +----+-------+ +----+-------+ +----+-------+ +----+-------+
Figure 2: Security Results Figure 2: Security Results
3.7. Block Integrity Block 3.8. 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.
o A security target listed in the Security Targets field MUST NOT o A security target listed in the Security Targets field MUST NOT
reference a security block defined in this specification (e.g., a reference a security block defined in this specification (e.g., a
BIB or a BCB). BIB or a BCB).
o The Cipher Suite Id MUST be documented as an end-to-end o The Security Association Id MUST refer to a known SA that supports
authentication-cipher suite or as an end-to-end error-detection- an end-to-end authentication-cipher suite or as an end-to-end
cipher suite. error-detection-cipher suite.
o An EID-reference to the security source MAY be present. If this o An EID-reference to the security source MAY be present. If this
field is not present, then the security source of the block SHOULD 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
key information described in Section 3.10. key information described in Section 3.11.
Notes: Notes:
o It is RECOMMENDED that cipher suite designers carefully consider o It is RECOMMENDED that SA designers carefully consider the effect
the effect of setting flags that either discard the block or of setting flags that either discard the block or delete the
delete the bundle in the event that this block cannot be bundle in the event that this block cannot be processed.
processed.
o Since OP(integrity, target) is allowed only once in a bundle per o Since OP(integrity, target) is allowed only once in a bundle per
target, it is RECOMMENDED that users wishing to support multiple target, it is RECOMMENDED that users wishing to support multiple
integrity signatures for the same target define a multi-signature integrity signatures for the same target define a multi-signature
cipher suite. SA.
o For some cipher suites, (e.g., those using asymmetric keying to o For some SAs, (e.g., those using asymmetric keying to produce
produce signatures or those using symmetric keying with a group signatures or those using symmetric keying with a group key), the
key), the security information MAY be checked at any hop on the security information MAY be checked at any hop on the way to the
way to the destination that has access to the required keying destination that has access to the required keying information, in
information, in accordance with Section 3.9. accordance with Section 3.10.
o The use of a generally available key is RECOMMENDED if custodial o The use of a generally available key is RECOMMENDED if custodial
transfer is employed and all nodes SHOULD verify the bundle before transfer is employed and all nodes SHOULD verify the bundle before
accepting custody. accepting custody.
3.8. Block Confidentiality Block 3.9. Block Confidentiality Block
A BCB is a bundle extension block with the following characteristics. A BCB is a bundle extension block with the following characteristics.
The Block Type Code value is as specified in Section 11.1. The Block Type Code value is as specified in Section 11.1.
The Block Processing Control flags value can be set to whatever The Block Processing Control flags value can be set to whatever
values are required by local policy, except that this block MUST values are required by local policy, except that this block MUST
have the "replicate in every fragment" flag set if the target of have the "replicate in every fragment" flag set if the target of
the BCB is the Payload Block. Having that BCB in each fragment the BCB is the Payload Block. Having that BCB in each fragment
indicates to a receiving node that the payload portion of each indicates to a receiving node that the payload portion of each
fragment represents cipher-text. fragment represents cipher-text.
The Block Type Specific Data Fields follow the structure of the The Block Type Specific Data Fields follow the structure of the
ASB. ASB.
A security target listed in the Security Targets field can A security target listed in the Security Targets field can
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 Cipher Suite Id MUST be documented as a confidentiality cipher The Security Association Id MUST refer to a known SA that supports
suite that supports authenticated encryption with associated data a confidentiality cipher suite that supports authenticated
(AEAD). encryption with associated data (AEAD).
Additional information created by a cipher suite (such as Additional information created by the SA (such as additional
additional authenticated data) can be placed either in a security authenticated data) can be placed either in a security result
result field or in the generated cipher-text. The determination field or in the generated cipher-text. The determination of where
of where to place these data is a function of the cipher suite to place these data is a function of the cipher suite used.
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
key information described in Section 3.10. key information described in Section 3.11.
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
field contains cipher-text, not plain-text. Other block fields field contains cipher-text, not plain-text. Other block fields
remain unmodified, with the exception of the Block Data Length field, remain unmodified, with the exception of the Block Data Length field,
which MUST be updated to reflect the new length of the Block Type which MUST be updated to reflect the new length of the Block Type
Specific Data field. Specific Data field.
Notes: Notes:
o It is RECOMMENDED that cipher suite designers carefully consider o It is RECOMMENDED that SA designers carefully consider the effect
the effect of setting flags that either discard the block or of setting flags that either discard the block or delete the
delete the bundle in the event that this block cannot be bundle in the event that this block cannot be processed.
processed.
o The BCB block processing control flags can be set independently o The BCB block processing control flags can be set independently
from the processing control flags of the security target(s). The from the processing control flags of the security target(s). The
setting of such flags SHOULD be an implementation/policy decision setting of such flags SHOULD be an implementation/policy decision
for the encrypting node. for the encrypting node.
3.9. Block Interactions 3.10. Block Interactions
The security block types defined in this specification are designed The security block types defined in this specification are designed
to be as independent as possible. However, there are some cases to be as independent as possible. However, there are some cases
where security blocks may share a security target creating processing where security blocks may share a security target creating processing
dependencies. dependencies.
If a security target of a BCB is also a security target of a BIB, an If a security target of a BCB is also a security target of a BIB, an
undesirable condition occurs where a security aware waypoint would be undesirable condition occurs where a security aware waypoint would be
unable to validate the BIB because one of its security target's unable to validate the BIB because one of its security target's
contents have been encrypted by a BCB. To address this situation the contents have been encrypted by a BCB. To address this situation the
skipping to change at page 17, line 38 skipping to change at page 20, line 14
o A BIB integrity value MUST NOT be evaluated if the BIB is the o A BIB integrity value MUST NOT be evaluated if the BIB is the
security target of an existing BCB. In this case, the BIB data is security target of an existing BCB. In this case, the BIB data is
encrypted. encrypted.
o A BIB integrity value MUST NOT be evaluated if the security target o A BIB integrity value MUST NOT be evaluated if the security target
of the BIB is also the security target of a BCB. In such a case, of the BIB is also the security target of a BCB. In such a case,
the security target data contains cipher-text as it has been the security target data contains cipher-text as it has been
encrypted. encrypted.
o As mentioned in Section 3.7, a BIB MUST NOT have a BCB as its o As mentioned in Section 3.8, a BIB MUST NOT have a BCB as its
security target. security target.
These restrictions on block interactions impose a necessary ordering These restrictions on block interactions impose a necessary ordering
when applying security operations within a bundle. Specifically, for when applying security operations within a bundle. Specifically, for
a given security target, BIBs MUST be added before BCBs. This a given security target, BIBs MUST be added before BCBs. This
ordering MUST be preserved in cases where the current BPA is adding ordering MUST be preserved in cases where the current BPA is adding
all of the security blocks for the bundle or whether the BPA is a all of the security blocks for the bundle or whether the BPA is a
waypoint adding new security blocks to a bundle that already contains waypoint adding new security blocks to a bundle that already contains
security blocks. security blocks.
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 possible 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. Cipher Suite Parameter and Result Identification 3.11. SA Parameters and Result Identification
Cipher suite parameters and security results each represent multiple SA parameters and security results each represent multiple distinct
distinct pieces of information in a security block. Each piece of pieces of information in a security block. Each piece of information
information is assigned an identifier and a CBOR encoding. is assigned an identifier and a CBOR encoding. Identifiers MUST be
Identifiers MUST be unique for a given cipher suite but do not need unique for a given SA but do not need to be unique across all SAs.
to be unique across all cipher suites. Therefore, parameter ids and Therefore, parameter ids and security result ids are specified in the
security result ids are specified in the context of a cipher suite context of an SA definition.
definition.
Individual BPSec cipher suites SHOULD use existing registries of Individual BPSec SAs SHOULD use existing registries of identifiers
identifiers and CBOR encodings, such as those defined in [RFC8152], and CBOR encodings, such as those defined in [RFC8152], whenever
whenever possible. Cipher suites SHOULD define their own identifiers possible. SAs SHOULD define their own identifiers and CBOR encodings
and CBOR encodings when necessary. when necessary.
A cipher suite can include multiple instances of the same identifier A SA can include multiple instances of the same identifier for a
for a parameter or result in a security block. Parameters and parameter or result in the SAB. Parameters and results are
results are represented using CBOR, and any identification of a new represented using CBOR, and any identification of a new parameter or
parameter or result must include how the value will be represented result must include how the value will be represented using the CBOR
using the CBOR specification. Ids themselves are always represented specification. Ids themselves are always represented as a CBOR
as a CBOR unsigned integer. unsigned integer.
3.11. BSP Block Examples 3.12. 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
of illustration. of illustration.
3.11.1. Example 1: Constructing a Bundle with Security 3.12.1. Example 1: Constructing a Bundle with Security
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, one of the the plain-text associated with the primary block, one of the
extension blocks, and the payload. The resultant bundle is extension blocks, and the payload. The resultant bundle is
illustrated in Figure 3 and the security actions are described below. illustrated in Figure 3 and the security actions are described below.
Block in Bundle ID Block in Bundle ID
+======================================+====+ +======================================+====+
skipping to change at page 19, line 45 skipping to change at page 22, line 17
o Confidentiality for the first extension block (B4). This is o Confidentiality for the first extension block (B4). This is
accomplished by a BCB (B3). Once applied, the contents of accomplished by a BCB (B3). Once applied, the contents of
extension block B4 are encrypted. The BCB MUST hold an extension block B4 are encrypted. The BCB MUST hold an
authentication signature for the cipher-text either in the cipher- authentication signature for the cipher-text either in the cipher-
text that now populated the first extension block or as a security text that now populated the first extension block or as a security
result in the BCB itself, depending on which cipher suite is used result in the BCB itself, depending on which cipher suite is used
to form the BCB. A plain-text integrity signature may also exist to form the BCB. A plain-text integrity signature may also exist
as a security result in the BCB if one is provided by the selected as a security result in the BCB if one is provided by the selected
confidentiality cipher suite. confidentiality cipher suite.
3.11.2. Example 2: Adding More Security At A New Node 3.12.2. Example 2: Adding More Security At A New Node
Consider that the bundle as it is illustrated in Figure 3 is now Consider that the bundle as it is illustrated in Figure 3 is now
received by a waypoint node that wishes to encrypt the first received by a waypoint node that wishes to encrypt the first
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
skipping to change at page 21, line 43 skipping to change at page 24, 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 used by SAs MAY define their own canonicalization
require the use of those algorithms over the ones provided in this algorithms and require the use of those algorithms over the ones
specification. In the event of conflicting canonicalization provided in this specification. In the event of conflicting
algorithms, cipher suite algorithms take precedence over this canonicalization algorithms, cipher suite algorithms take precedence
specification. 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.
skipping to change at page 32, line 40 skipping to change at page 35, line 40
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 cipher suite identifiers will be required. A registry of cipher suite identifiers will be required.
11.1. Bundle Block Types 11.1. Bundle Block Types
This specification allocates two block types from the existing This specification allocates three block types from the existing
"Bundle Block Types" registry defined in [RFC6255]. "Bundle Block Types" registry defined in [RFC6255].
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 | Security Association Block | This document |
| TBD | Block Integrity Block | This document | | TBD | Block Integrity Block | This document |
| TBD | Block Confidentiality Block | This document | | TBD | Block Confidentiality Block | This document |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
Table 1 Table 1
12. References 12. References
12.1. Normative References 12.1. Normative References
 End of changes. 45 change blocks. 
148 lines changed or deleted 243 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/