draft-ietf-dtn-bpsec-13.txt		draft-ietf-dtn-bpsec-14.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		Obsoletes: 6257 (if approved) JHU/APL
	Expires: May 7, 2020 November 4, 2019		Intended status: Standards Track January 16, 2020
			Expires: July 19, 2020
	Bundle Protocol Security Specification		Bundle Protocol Security Specification
	draft-ietf-dtn-bpsec-13		draft-ietf-dtn-bpsec-14
	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.
			The Internet Research Task Force is advised that this document is an
			update of the protocol described in [RFC6257], reflecting lessons
			learned. The Internet Research Task Force is requested to mark
			[RFC6257] as obsolete.
	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.
	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 May 7, 2020.		This Internet-Draft will expire on July 19, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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 . . . . . . . . . . . . . . . 4
	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 . . . . . . . . . . . . . . . . 8		2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8
	2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8		2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8
	2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9		2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9
	2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9		2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9
	3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9		3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10
	3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9		3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 10
	3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10		3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10
	3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11		3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11
	3.4. Target Identification . . . . . . . . . . . . . . . . . . 11		3.4. Target Identification . . . . . . . . . . . . . . . . . . 12
	3.5. Block Representation . . . . . . . . . . . . . . . . . . 12		3.5. Block Representation . . . . . . . . . . . . . . . . . . 12
	3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12		3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12
	3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15		3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15
	3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16		3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16
	3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17		3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17
	3.10. Parameter and Result Identification . . . . . . . . . . . 18		3.10. Parameter and Result Identification . . . . . . . . . . . 18
	3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 19		3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 19
	3.11.1. Example 1: Constructing a Bundle with Security . . . 19		3.11.1. Example 1: Constructing a Bundle with Security . . . 19
	3.11.2. Example 2: Adding More Security At A New Node . . . 20		3.11.2. Example 2: Adding More Security At A New Node . . . 20
	4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22		4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 20
	5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22		5. Security Processing . . . . . . . . . . . . . . . . . . . . . 21
	5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23		5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 21
	5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23		5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 21
	5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24		5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 22
	5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 25		5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 23
	6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 25		6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 24
	7. Security Policy Considerations . . . . . . . . . . . . . . . 25		7. Security Policy Considerations . . . . . . . . . . . . . . . 24
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 27		8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	8.1. Attacker Capabilities and Objectives . . . . . . . . . . 27		8.1. Attacker Capabilities and Objectives . . . . . . . . . . 26
	8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 28		8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 27
	8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 28		8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 27
	8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29		8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 27
	8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30		8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 28
	8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 30		8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 29
	9. Security Context Considerations . . . . . . . . . . . . . . . 31		9. Security Context Considerations . . . . . . . . . . . . . . . 29
	9.1. Identification and Configuration . . . . . . . . . . . . 31		9.1. Identification and Configuration . . . . . . . . . . . . 29
	9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 31		9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 30
	10. Defining Other Security Blocks . . . . . . . . . . . . . . . 33		10. Defining Other Security Blocks . . . . . . . . . . . . . . . 32
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 34		11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 33
	11.2. Security Context Identifiers . . . . . . . . . . . . . . 34		11.2. Security Context Identifiers . . . . . . . . . . . . . . 33
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	12.1. Normative References . . . . . . . . . . . . . . . . . . 35		12.1. Normative References . . . . . . . . . . . . . . . . . . 34
	12.2. Informative References . . . . . . . . . . . . . . . . . 35		12.2. Informative References . . . . . . . . . . . . . . . . . 34
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
	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 3, line 40 ¶		skipping to change at page 3, line 44 ¶
	transport security mechanisms may not be sufficient. For example,		transport security mechanisms may not be sufficient. For example,
	the store-carry-forward nature of the network may require protecting		the store-carry-forward nature of the network may require protecting
	data at rest, preventing unauthorized consumption of critical		data at rest, preventing unauthorized consumption of critical
	resources such as storage space, and operating without regular		resources such as storage space, and operating without regular
	contact with a centralized security oracle (such as a certificate		contact with a centralized security oracle (such as a certificate
	authority).		authority).
	An end-to-end security service is needed that operates in all of the		An end-to-end security service is needed that operates in all of the
	environments where the BP operates.		environments where the BP operates.
			The Internet Research Task Force is advised that this document is an
			update of the protocol described in [RFC6257], reflecting lessons
			learned. The Internet Research Task Force is requested to mark
			[RFC6257] as obsolete.
	1.1. Supported Security Services		1.1. Supported Security Services
	BPSec provides end-to-end integrity and confidentiality services for		BPSec provides end-to-end integrity and confidentiality services for
	BP bundles, as defined in this section.		BP bundles, as defined in this section.
	Integrity services ensure that changes to target data within a bundle		Integrity services ensure that changes to target data within a bundle
	can be discovered. Data changes may be caused by processing errors,		can be discovered. Data changes may be caused by processing errors,
	environmental conditions, or intentional manipulation. In the		environmental conditions, or intentional manipulation. In the
	context of BPSec, integrity services apply to plain-text in the		context of BPSec, integrity services apply to plain-text in the
	bundle.		bundle.
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 39 ¶
	"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		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 payload of the bundle to an application. Also, the Node ID of
	the Bundle Protocol Agent (BPA) receiving the bundle. The bundle		the Bundle Protocol Agent (BPA) receiving the bundle. The bundle
	destination acts as the security destination for every security		destination acts as the security acceptor for every security
	target in every security block in every bundle it receives.		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,
	skipping to change at page 6, line 48 ¶		skipping to change at page 7, line 13 ¶
	hop.		hop.
	o Intermediate Receiver, Waypoint, or Next Hop - any node that		o Intermediate Receiver, Waypoint, or Next Hop - any node that
	receives a bundle from a Forwarder that is not the Bundle		receives a bundle from a Forwarder that is not the Bundle
	Destination. Also, the Node ID of the BPA at any such node.		Destination. Also, the Node ID of the BPA at any such node.
	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 Acceptor - a bundle node that processes and dispositions
			one or more security blocks in a bundle. Also, the Node ID of
			that node.
	o Security Block - a BPSec extension block in a bundle.		o Security Block - a BPSec extension block in a bundle.
	o Security Context - the set of assumptions, algorithms,		o Security Context - the set of assumptions, algorithms,
	configurations and policies used to implement security services.		configurations and policies used to implement security services.
	o Security 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 8, line 45 ¶		skipping to change at page 9, line 12 ¶
	The security policy enforced by nodes in the DTN may differ.		The security policy enforced by nodes in the DTN may differ.
	Some waypoints might not be security aware and will not be able to		Some waypoints might not be security aware and will not be able to
	process security blocks. Therefore, security blocks must have their		process security blocks. Therefore, security blocks must have their
	processing flags set such that the block will be treated		processing flags set such that the block will be treated
	appropriately by non-security-aware waypoints.		appropriately by non-security-aware waypoints.
	Some waypoints will have security policies that require evaluating		Some waypoints will have security policies that require evaluating
	security services even if they are not the bundle destination or the		security services even if they are not the bundle destination or the
	final intended destination of the service. For example, a waypoint		final intended acceptor of the service. For example, a waypoint
	could choose to verify an integrity service even though the waypoint		could choose to verify an integrity service even though the waypoint
	is not the bundle destination and the integrity service will be		is not the bundle destination and the integrity service will be
	needed by other nodes along the bundle's path.		needed by other nodes along the bundle's path.
	Some waypoints will determine, through policy, that they are the		Some waypoints will determine, through policy, that they are the
	intended recipient of the security service and terminate the security		intended recipient of the security service and terminate the security
	service in the bundle. For example, a gateway node could determine		service in the bundle. For example, a gateway node could determine
	that, even though it is not the destination of the bundle, it should		that, even though it is not the destination of the bundle, it should
	verify and remove a particular integrity service or attempt to		verify and remove a particular integrity service or attempt to
	decrypt a confidentiality service, before forwarding the bundle along		decrypt a confidentiality service, before forwarding the bundle along
	skipping to change at page 11, line 41 ¶		skipping to change at page 12, line 4 ¶
	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.
	It is RECOMMENDED that if a node processes any security operation in		It is RECOMMENDED that if a node processes any security operation in
	a security block that it process all security operations in the		a security block that it process all security operations in the
	security block. This allows security sources to assert that the set		security block. This allows security sources to assert that the set
	of security operations in a security block are expected to be		of security operations in a security block are expected to be
	processed by the same security destination. However, the		processed by the same security acceptor. However, the determination
	determination of whether a node actually is a security destination or		of whether a node actually is a security acceptor or not is a matter
	not is a matter of the policy of the node itself. In cases where a		of the policy of the node itself. In cases where a receiving node
	receiving node determines that it is the security destination of only		determines that it is the security acceptor of only a subset of the
	a subset of the security operations in a security block, the node may		security operations in a security block, the node may choose to only
	choose to only process that subset of security operations.		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 14, line 20 ¶		skipping to change at page 14, line 31 ¶
	in Section 3.10.		in Section 3.10.
	* Parameter Value. This field captures the value associated		* Parameter Value. This field captures the value associated
	with this parameter. This field SHALL be represented by the		with this parameter. This field SHALL be represented by the
	applicable CBOR representation of the parameter, in		applicable CBOR representation of the parameter, in
	accordance with Section 3.10.		accordance with Section 3.10.
	The logical layout of the parameters array is illustrated in		The logical layout of the parameters array is illustrated in
	Figure 1.		Figure 1.
	+----------------+----------------+ +----------------+
	| Parameter 1 | Parameter 2 | ... | Parameter N |
	+------+---------+------+---------+ +------+---------+
	| Id | Value | Id | Value | | Id | Value |
	+------+---------+------+---------+ +------+---------+
	Figure 1: Security Context Parameters		Figure 1: Security Context Parameters
	Security Results:		Security Results:
	This field captures the results of applying a security service		This field captures the results of applying a security service
	to the security targets of the security block. This field		to the security targets of the security block. This field
	SHALL be represented as a CBOR array of target results. Each		SHALL be represented as a CBOR array of target results. Each
	entry in this array represents the set of security results for		entry in this array represents the set of security results for
	a specific security target. The target results MUST be ordered		a specific security target. The target results MUST be ordered
	identically to the Security Targets field of the security		identically to the Security Targets field of the security
	block. This means that the first set of target results in this		block. This means that the first set of target results in this
	skipping to change at page 15, line 17 ¶		skipping to change at page 15, line 23 ¶
	* Result Value. This field captures the value associated with		* Result Value. This field captures the value associated with
	the result. This field SHALL be represented by the		the result. This field SHALL be represented by the
	applicable CBOR representation of the result value, in		applicable CBOR representation of the result value, in
	accordance with Section 3.10.		accordance with Section 3.10.
	The logical layout of the security results array is illustrated		The logical layout of the security results array is illustrated
	in Figure 2. In this figure there are N security targets for		in Figure 2. In this figure there are N security targets for
	this security block. The first security target contains M		this security block. The first security target contains M
	results and the Nth security target contains K results.		results and the Nth security target contains K results.
	+------------------------------+ +------------------------------+
	| Target 1 | | Target N |
	+------------+----+------------+ +------------------------------+
	| Result 1 | | Result M | ... | Result 1 | | Result K |
	+----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+
	| Id | Value | | Id | Value | | Id | Value | | Id | Value |
	+----+-------+ +----+-------+ +----+-------+ +----+-------+
	Figure 2: Security Results		Figure 2: Security Results
	3.7. Block Integrity Block		3.7. Block Integrity Block
	A BIB is a bundle extension block with the following characteristics.		A BIB is a bundle extension block with the following characteristics.
	o The Block Type Code value is as specified in Section 11.1.		o The Block Type Code value is as specified in Section 11.1.
	o The Block Type Specific Data Fields follow the structure of the		o The Block Type Specific Data Fields follow the structure of the
	ASB.		ASB.
	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 Security Context Id MUST utilize an end-to-end authentication		o The Security Context Id MUST utilize an end-to-end authentication
	cipher or an end-to-end error detection cipher.		cipher or an end-to-end error detection cipher.
	o An EID-reference to the security source MAY be present. If this		o The EID of the security source MAY be present. If this field is
	field is not present, then the security source of the block SHOULD		not present, then the security source of the block SHOULD be
	be inferred according to security policy and MAY default to the		inferred according to security policy and MAY default to the
	bundle source. The security source MAY be specified as part of		bundle source. The security source MAY be specified as part of
	security context information described in Section 3.10.		security context information described in Section 3.10.
	Notes:		Notes:
	o It is RECOMMENDED that designers carefully consider the effect of		o It is RECOMMENDED that designers carefully consider the effect of
	setting flags that either discard the block or delete the bundle		setting flags that either discard the block or delete the bundle
	in the event that this block cannot be processed.		in the event that this block cannot be 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
	security context.		security context.
	o For some security contexts, (e.g., those using asymmetric keying		o For some security contexts, (e.g., those using asymmetric keying
	to produce signatures or those using symmetric keying with a group		to produce signatures or those using symmetric keying with a group
	key), the security information MAY be checked at any hop on the		key), the security information MAY be checked at any hop on the
	way to the destination that has access to the required keying		way to the bundle destination that has access to the required
	information, in accordance with Section 3.9.		keying information, in accordance with Section 3.9.
	3.8. Block Confidentiality Block		3.8. 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
	skipping to change at page 16, line 50 ¶		skipping to change at page 16, line 46 ¶
	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 and		of where to place these data is a function of the cipher suite and
	security context used.		security context used.
	An EID-reference to the security source MAY be present. If this		The EID of the security source MAY be present. If this field is
	field is not present, then the security source of the block SHOULD		not present, then the security source of the block SHOULD be
	be inferred according to security policy and MAY default to the		inferred according to security policy and MAY default to the
	bundle source. The security source MAY be specified as part of		bundle source. The security source MAY be specified as part of
	security context information described in Section 3.10.		security context 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
	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.
	skipping to change at page 18, line 36 ¶		skipping to change at page 18, line 33 ¶
	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		Since any cipher suite used with a BCB MUST be an AEAD cipher suite,
	suite, it is inefficient and possibly insecure for a single security		it is inefficient and insecure for a single security source to add
	source to add both a BIB and a BCB for the same security target. In		both a BIB and a BCB for the same security target. In cases where a
	cases where a security source wishes to calculate both a plain-text		security source wishes to calculate both a plain-text integrity
	integrity mechanism and encrypt a security target, a BCB with a		mechanism and encrypt a security target, a BCB with a security
	security context that generates such signatures as additional		context that generates such signatures as additional security results
	security results SHOULD be used instead.		MUST be used instead.
	3.10. Parameter and Result Identification		3.10. Parameter and Result Identification
	Each security context MUST define its own context parameters and		Each security context MUST define its own context parameters and
	results. Each defined parameter and result is represented as the		results. Each defined parameter and result is represented as the
	tuple of an identifier and a value. Identifiers are always		tuple of an identifier and a value. Identifiers are always
	represented as a CBOR unsigned integer. The CBOR encoding of values		represented as a CBOR unsigned integer. The CBOR encoding of values
	is as defined by the security context specification.		is as defined by the security context specification.
	Identifiers MUST be unique for a given security context but do not		Identifiers MUST be unique for a given security context but do not
	skipping to change at page 19, line 30 ¶		skipping to change at page 19, line 27 ¶
	In this example a bundle has four non-security-related blocks: the		In this example a bundle has four non-security-related blocks: the
	primary block (B1), two extension blocks (B4,B5), and a payload block		primary block (B1), two extension blocks (B4,B5), and a payload block
	(B6). The bundle source wishes to provide an integrity signature of		(B6). The bundle source wishes to provide an integrity signature of
	the plain-text associated with the primary block, the second		the plain-text associated with the primary block, the second
	extension block, and the payload. The bundle source also wishes to		extension block, and the payload. The bundle source also wishes to
	provide confidentiality for the first extension block. The resultant		provide confidentiality for the first extension block. The resultant
	bundle is illustrated in Figure 3 and the security actions are		bundle is illustrated in Figure 3 and the security actions are
	described below.		described below.
	Block in Bundle ID
	+======================================+====+
	| Primary Block | B1 |
	+--------------------------------------+----+
	| BIB | B2 |
	| OP(integrity, targets=B1, B5, B6) | |
	+--------------------------------------+----+
	| BCB | B3 |
	| OP(confidentiality, target=B4) | |
	+--------------------------------------+----+
	| Extension Block (encrypted) | B4 |
	+--------------------------------------+----+
	| Extension Block | B5 |
	+--------------------------------------+----+
	| Payload Block | B6 |
	+--------------------------------------+----+
	Figure 3: Security at Bundle Creation		Figure 3: Security at Bundle Creation
	The following security actions were applied to this bundle at its		The following security actions were applied to this bundle at its
	time of creation.		time of creation.
	o An integrity signature applied to the canonicalized primary block		o An integrity signature applied to the canonicalized primary block
	(B1), the second extension block (B5) and the payload block (B6).		(B1), the second extension block (B5) and the payload block (B6).
	This is accomplished by a single BIB (B2) with multiple targets.		This is accomplished by a single BIB (B2) with multiple targets.
	A single BIB is used in this case because all three targets share		A single BIB is used in this case because all three targets share
	a security source, security context, and security context		a security source, security context, and security context
	skipping to change at page 21, line 5 ¶		skipping to change at page 20, line 19 ¶
	extension block and the bundle payload. The waypoint security policy		extension block and the bundle payload. The waypoint security policy
	is to allow existing BIBs for these blocks to persist, as they may be		is to allow existing BIBs for these blocks to persist, as they may be
	required as part of the security policy at the bundle destination.		required as part of the security policy at the bundle destination.
	The resultant bundle is illustrated in Figure 4 and the security		The resultant bundle is illustrated in Figure 4 and the security
	actions are described below. Note that block IDs provided here are		actions are described below. Note that block IDs provided here are
	ordered solely for the purpose of this example and not meant to		ordered solely for the purpose of this example and not meant to
	impose an ordering for block creation. The ordering of blocks added		impose an ordering for block creation. The ordering of blocks added
	to a bundle MUST always be in compliance with [I-D.ietf-dtn-bpbis].		to a bundle MUST always be in compliance with [I-D.ietf-dtn-bpbis].
	Block in Bundle ID
	+======================================+====+
	| Primary Block | B1 |
	+--------------------------------------+----+
	| BIB | B2 |
	| OP(integrity, targets=B1) | |
	+--------------------------------------+----+
	| BIB (encrypted) | B7 |
	| OP(integrity, targets=B5, B6) | |
	+--------------------------------------+----+
	| BCB | B8 |
	| OP(confidentiality, target=B5,B6,B7) | |
	+--------------------------------------+----+
	| BCB | B3 |
	| OP(confidentiality, target=B4) | |
	+--------------------------------------+----+
	| Extension Block (encrypted) | B4 |
	+--------------------------------------+----+
	| Extension Block (encrypted) | B5 |
	+--------------------------------------+----+
	| Payload Block (encrypted) | B6 |
	+--------------------------------------+----+
	Figure 4: Security At Bundle Forwarding		Figure 4: Security At Bundle Forwarding
	The following security actions were applied to this bundle prior to		The following security actions were applied to this bundle prior to
	its forwarding from the waypoint node.		its forwarding from the waypoint node.
	o Since the waypoint node wishes to encrypt blocks B5 and B6, it		o Since the waypoint node wishes to encrypt blocks B5 and B6, it
	MUST also encrypt the BIBs providing plain-text integrity over		MUST also encrypt the BIBs providing plain-text integrity over
	those blocks. However, BIB B2 could not be encrypted in its		those blocks. However, BIB B2 could not be encrypted in its
	entirety because it also held a signature for the primary block		entirety because it also held a signature for the primary block
	(B1). Therefore, a new BIB (B7) is created and security results		(B1). Therefore, a new BIB (B7) is created and security results
	skipping to change at page 23, line 16 ¶		skipping to change at page 21, line 51 ¶
	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 is the security destination for any of the		determine whether it is the security acceptor for any of the security
	security operations in the BCB. If so, the node MUST process those		operations in the BCB. If so, the node MUST process those operations
	operations and remove any operation-specific information from the BCB		and remove any operation-specific information from the BCB prior to
	prior to delivering data to an application at the node or forwarding		delivering data to an application at the node or forwarding the
	the bundle. If processing a security operation fails, the target		bundle. If processing a security operation fails, the target SHALL
	SHALL be processed according to the security policy. A bundle status		be processed according to the security policy. A bundle status
	report indicating the failure MAY be generated. When all security		report indicating the failure MAY be generated. When all security
	operations for a BCB have been removed from the BCB, the BCB MUST be		operations for a BCB have been removed from the BCB, the BCB MUST be
	removed from the bundle.		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 process 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
	skipping to change at page 24, line 13 ¶		skipping to change at page 22, line 47 ¶
	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 operations, each operation		If a BCB contains multiple security operations, each operation
	processed by the node MUST be be treated as if the security operation		processed by the node MUST be be treated as if the security operation
	has been represented by a single BCB with a single security operation		has been represented by a single BCB with a single security operation
	for the purposes of report generation and policy processing.		for the purposes of report generation and policy processing.
	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 is the security destination for any of the		determine whether it is the security acceptor for any of the security
	security operations in the BIB. If so, the node MUST process those		operations in the BIB. If so, the node MUST process those operations
	operations and remove any operation-specific information from the BIB		and remove any operation-specific information from the BIB prior to
	prior to delivering data to an application at the node or forwarding		delivering data to an application at the node or forwarding the
	the bundle. If processing a security operation fails, the target		bundle. If processing a security operation fails, the target SHALL
	SHALL be processed according to the security policy. A bundle status		be processed according to the security policy. A bundle status
	report indicating the failure MAY be generated. When all security		report indicating the failure MAY be generated. When all security
	operations for a BIB have been removed from the BIB, the BIB MUST be		operations for a BIB have been removed from the BIB, the BIB MUST be
	removed from the bundle.		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
	skipping to change at page 24, line 41 ¶		skipping to change at page 23, line 27 ¶
	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 is not the security destination of a security		If a receiving node is not the security acceptor of a security
	operation in a BIB it MAY attempt to verify the security operation		operation in a BIB it MAY attempt to verify the security operation
	anyway to prevent forwarding corrupt data. If the verification		anyway to prevent forwarding corrupt data. If the verification
	fails, the node SHALL process the security target in accordance to		fails, the node SHALL process the security target in accordance to
	local security policy. It is RECOMMENDED that if a payload integrity		local security policy. It is RECOMMENDED that if a payload integrity
	check fails at a waypoint that it is processed in the same way as if		check fails at a waypoint that it is processed in the same way as if
	the check fails at the bundle destination. If the check passes, the		the check fails at the bundle destination. If the check passes, the
	node MUST NOT remove the security operation from the BIB prior to		node MUST NOT remove the security operation from the BIB prior to
	forwarding.		forwarding.
	If a BIB contains multiple security operations, each operation		If a BIB contains multiple security operations, each operation
	skipping to change at page 31, line 36 ¶		skipping to change at page 30, line 24 ¶
	of contexts can be defined with each context supporting few, if any,		of contexts can be defined with each context supporting few, if any,
	parameters.		parameters.
	Security Context Examples		Security Context Examples
	+---------+------------+--------------------------------------------+		+---------+------------+--------------------------------------------+
	| Context | Parameters | Definition |		| Context | Parameters | Definition |
	| Id | | |		| Id | | |
	+---------+------------+--------------------------------------------+		+---------+------------+--------------------------------------------+
	| 1 | Key, IV | AES-GCM-256 cipher suite with provided |		| 1 | Key, IV | AES-GCM-256 cipher suite with provided |
	| | | ephemeral key and initialization vector. |		| | | ephemeral key and |
			| | | initialization vector. |
	| 2 | IV | AES-GCM-256 cipher suite with |		| 2 | IV | AES-GCM-256 cipher suite with |
	| | | predetermined key and predetermined key |		| | | predetermined key and predetermined |
	| | | rotation policy. |		| | | key rotation policy. |
	| 3 | Nil | AES-GCM-256 cipher suite with all info |		| 3 | Nil | AES-GCM-256 cipher suite with all info |
	| | | predetermined. |		| | | predetermined. |
	+---------+------------+--------------------------------------------+		+---------+------------+--------------------------------------------+
	Table 1		Table 1
	9.2. Authorship		9.2. Authorship
	Developers or implementers should consider the diverse performance		Developers or implementers should consider the diverse performance
	and conditions of networks on which the Bundle Protocol (and		and conditions of networks on which the Bundle Protocol (and
	skipping to change at page 34, line 37 ¶		skipping to change at page 33, line 28 ¶
	+-------+-----------------------------+---------------+		+-------+-----------------------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+-----------------------------+---------------+		+-------+-----------------------------+---------------+
	| 11 | Block Integrity Block | This document |		| 11 | Block Integrity Block | This document |
	| 12 | Block Confidentiality Block | This document |		| 12 | Block Confidentiality Block | This document |
	+-------+-----------------------------+---------------+		+-------+-----------------------------+---------------+
	Table 2		Table 2
			The Bundle Block Types namespace notes whether a block type is meant
			for use in BP version 6, BP version 7, or both. The two block types
			defined in this specification are meant for use with BP version 7.
	11.2. Security Context Identifiers		11.2. Security Context Identifiers
	BPSec has a Security Context Identifier field for which IANA is		BPSec has a Security Context Identifier field for which IANA is
	requested to create and maintain a new registry named "BPSec Security		requested to create and maintain a new registry named "BPSec Security
	Context Identifiers". Initial values for this registry are given		Context Identifiers". Initial values for this registry are given
	below.		below.
	The registration policy for this registry is: Specification Required.		The registration policy for this registry is: Specification Required.
	The value range is: unsigned 16-bit integer.		The value range is: unsigned 16-bit integer.
	skipping to change at page 35, line 21 ¶		skipping to change at page 34, line 11 ¶
	+-------+-------------+---------------+		+-------+-------------+---------------+
	Table 3		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-14 (work in progress),		Version 7", draft-ietf-dtn-bpbis-18 (work in progress),
	August 2019.		January 2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,		Text on Security Considerations", BCP 72, RFC 3552,
	DOI 10.17487/RFC3552, July 2003,		DOI 10.17487/RFC3552, July 2003,
	<https://www.rfc-editor.org/info/rfc3552>.		<https://www.rfc-editor.org/info/rfc3552>.
	skipping to change at page 36, line 27 ¶		skipping to change at page 35, line 17 ¶
	The following participants contributed technical material, use cases,		The following participants contributed technical material, use cases,
	and useful thoughts on the overall approach to this security		and useful thoughts on the overall approach to this security
	specification: Scott Burleigh of the Jet Propulsion Laboratory, Amy		specification: Scott Burleigh of the Jet Propulsion Laboratory, Amy
	Alford and Angela Hennessy of the Laboratory for Telecommunications		Alford and Angela Hennessy of the Laboratory for Telecommunications
	Sciences, and Angela Dalton and Cherita Corbett of the Johns Hopkins		Sciences, and Angela Dalton and Cherita Corbett of the Johns Hopkins
	University Applied Physics Laboratory.		University Applied Physics Laboratory.
	Authors' Addresses		Authors' Addresses
	Edward J. Birrane, III		Edward J. Birrane, III
	The Johns Hopkins University Applied Physics Laboratory		The Johns Hopkins University Applied
			Physics Laboratory
	11100 Johns Hopkins Rd.		11100 Johns Hopkins Rd.
	Laurel, MD 20723		Laurel, MD 20723
	US		US
	Phone: +1 443 778 7423		Phone: +1 443 778 7423
	Email: Edward.Birrane@jhuapl.edu		Email: Edward.Birrane@jhuapl.edu
	Kenneth McKeever		Kenneth McKeever
	The Johns Hopkins University Applied Physics Laboratory		The Johns Hopkins University Applied
			Physics Laboratory
	11100 Johns Hopkins Rd.		11100 Johns Hopkins Rd.
	Laurel, MD 20723		Laurel, MD 20723
	US		US
	Phone: +1 443 778 2237		Phone: +1 443 778 2237
	Email: Ken.McKeever@jhuapl.edu		Email: Ken.McKeever@jhuapl.edu
End of changes. 32 change blocks.
	136 lines changed or deleted		101 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/