draft-ietf-dtn-bpsec-20.txt		draft-ietf-dtn-bpsec-21.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: August 10, 2020 February 7, 2020		Expires: September 2, 2020 March 1, 2020
	Bundle Protocol Security Specification		Bundle Protocol Security Specification
	draft-ietf-dtn-bpsec-20		draft-ietf-dtn-bpsec-21
	Abstract		Abstract
	This document defines a security protocol providing data integrity		This document defines a security protocol providing data integrity
	and confidentiality services for the Bundle Protocol.		and confidentiality services for the Bundle Protocol.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 10, 2020.		This Internet-Draft will expire on September 2, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Supported Security Services . . . . . . . . . . . . . . . 3		1.1. Supported Security Services . . . . . . . . . . . . . . . 3
	1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4		1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4
	1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5		1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5
	1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 7		2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 7		2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 7
	2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8		2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8
	2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8		2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 9
	2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9		2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9
	2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9		2.5. Deterministic Processing . . . . . . . . . . . . . . . . 10
	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 . . . . . . . . . . . . . . . . . . 12		3.4. Target Identification . . . . . . . . . . . . . . . . . . 12
	3.5. Block Representation . . . . . . . . . . . . . . . . . . 12		3.5. Block Representation . . . . . . . . . . . . . . . . . . 13
	3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12		3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 13
	3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15		3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 16
	3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16		3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 17
	3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17		3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 18
	3.10. Parameter and Result Identification . . . . . . . . . . . 18		3.10. Parameter and Result Identification . . . . . . . . . . . 19
	3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 19		3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 20
	3.11.1. Example 1: Constructing a Bundle with Security . . . 19		3.11.1. Example 1: Constructing a Bundle with Security . . . 20
	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 . . . 21
	4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22		4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 23
	5. Security Processing . . . . . . . . . . . . . . . . . . . . . 23		5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24
	5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23		5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 24
	5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23		5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 24
	5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24		5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 25
	5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 25		5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 26
	6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 25		6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 26
	7. Security Policy Considerations . . . . . . . . . . . . . . . 25		7. Security Policy Considerations . . . . . . . . . . . . . . . 26
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 27		8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	8.1. Attacker Capabilities and Objectives . . . . . . . . . . 27		8.1. Attacker Capabilities and Objectives . . . . . . . . . . 28
	8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 28		8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 29
	8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 28		8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 29
	8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29		8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 30
	8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30		8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 31
	8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 31		8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 32
	9. Security Context Considerations . . . . . . . . . . . . . . . 31		9. Security Context Considerations . . . . . . . . . . . . . . . 32
	9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 31		9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 32
	9.2. Identification and Configuration . . . . . . . . . . . . 32		9.2. Identification and Configuration . . . . . . . . . . . . 33
	9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 33		9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 34
	10. Defining Other Security Blocks . . . . . . . . . . . . . . . 34		10. Defining Other Security Blocks . . . . . . . . . . . . . . . 35
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 36		11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 37
	11.2. Security Context Identifiers . . . . . . . . . . . . . . 36		11.2. Security Context Identifiers . . . . . . . . . . . . . . 37
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
	12.1. Normative References . . . . . . . . . . . . . . . . . . 36		12.1. Normative References . . . . . . . . . . . . . . . . . . 37
	12.2. Informative References . . . . . . . . . . . . . . . . . 37		12.2. Informative References . . . . . . . . . . . . . . . . . 38
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	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 security services between a security		Networks (DTNs) to provide security services between a security
	source and a security acceptor. When the security source is the		source and a security acceptor. When the security source is the
	bundle source and when the security acceptor is the bundle		bundle source and when the security acceptor is the bundle
	destination, the security service provides end-to-end protection.		destination, the security service provides end-to-end protection.
	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
	as sitting at the application layer of some number of constituent		as sitting at the application layer of some number of constituent
	networks, forming a store-carry-forward overlay network". The term		networks, forming a store-carry-forward overlay network". The term
	"stressed" environment refers to multiple challenging conditions		"stressed" environment refers to multiple challenging conditions
	including intermittent connectivity, large and/or variable delays,		including intermittent connectivity, large and/or variable delays,
	asymmetric data rates, and high bit error rates.		asymmetric data rates, and high bit error rates.
	The BP might be deployed such that portions of the network cannot be		It should be presumed that the BP will be deployed such that the
	trusted, posing the usual security challenges related to		network cannot be trusted, posing the usual security challenges
	confidentiality and integrity. However, the stressed nature of the		related to confidentiality and integrity. However, the stressed
	BP operating environment imposes unique conditions where usual		nature of the BP operating environment imposes unique conditions
	transport security mechanisms may not be sufficient. For example,		where usual transport security mechanisms may not be sufficient. For
	the store-carry-forward nature of the network may require protecting		example, the store-carry-forward nature of the network may require
	data at rest, preventing unauthorized consumption of critical		protecting data at rest, preventing unauthorized consumption of
	resources such as storage space, and operating without regular		critical resources such as storage space, and operating without
	contact with a centralized security oracle (such as a certificate		regular contact with a centralized security oracle (such as a
	authority).		certificate 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.
	1.1. Supported Security Services		1.1. Supported Security Services
	BPSec provides integrity and confidentiality services for BP bundles,		BPSec provides integrity and confidentiality services for BP bundles,
	as defined in this section.		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
	skipping to change at page 5, line 9 ¶		skipping to change at page 5, line 9 ¶
	not address threats which share computing resources with the DTN and/		not address threats which share computing resources with the DTN and/
	or BPSec software implementations. These threats may be malicious		or BPSec software implementations. These threats may be malicious
	software or compromised libraries which intend to intercept data or		software or compromised libraries which intend to intercept data or
	recover cryptographic material. Here, it is the responsibility of		recover cryptographic material. Here, it is the responsibility of
	the BPSec implementer to ensure that any cryptographic material,		the BPSec implementer to ensure that any cryptographic material,
	including shared secret or private keys, is protected against access		including shared secret or private keys, is protected against access
	within both memory and storage devices.		within both memory and storage devices.
	This specification addresses neither the fitness of externally-		This specification addresses neither the fitness of externally-
	defined cryptographic methods nor the security of their		defined cryptographic methods nor the security of their
	implementation. Different networking conditions and operational		implementation. Completely trusted networks are extremely uncommon.
	considerations require varying strengths of security mechanism such		Amongst untrusted networks, different networking conditions and
	that mandating a cipher suite in this specification may result in too		operational considerations require varying strengths of security
	much security for some networks and too little security in others.		mechanism. Mandating a cipher suite in this specification may result
	It is expected that separate documents will be standardized to define		in too much security for some networks and too little security in
	security contexts and cipher suites compatible with BPSec, to include		others. It is expected that separate documents will be standardized
	those that should be used to assess interoperability and those fit		to define security contexts and cipher suites compatible with BPSec,
	for operational use in various network scenarios. A sample security		to include those that should be used to assess interoperability and
	context has been defined ([I-D.ietf-dtn-bpsec-interop-sc]) to support		those fit for operational use in various network scenarios. A sample
	interoperability testing and serve as an exemplar for how security		security context has been defined ([I-D.ietf-dtn-bpsec-interop-sc])
	contexts should be defined for this specification.		to support interoperability testing and serve as an exemplar for how
			security contexts should be defined for this specification.
	This specification does not address the implementation of security		This specification does not address the implementation of security
	policy and does not provide a security policy for the BPSec. Similar		policy and does not provide a security policy for the BPSec. Similar
	to cipher suites, security policies are based on the nature and		to cipher suites, security policies are based on the nature and
	capabilities of individual networks and network operational concepts.		capabilities of individual networks and network operational concepts.
	This specification does provide policy considerations when building a		This specification does provide policy considerations when building a
	security policy.		security policy.
	With the exception of the Bundle Protocol, this specification does		With the exception of the Bundle Protocol, this specification does
	not address how to combine the BPSec security blocks with other		not address how to combine the BPSec security blocks with other
	skipping to change at page 7, line 29 ¶		skipping to change at page 7, line 35 ¶
	o Security Source - a bundle node that adds a security block to a		o Security Source - a bundle node that adds a security block to a
	bundle. Also, the Node ID of that node.		bundle. Also, the Node ID of that node.
	o Security Target - the block within a bundle that receives a		o Security Target - the block within a bundle that receives a
	security service as part of a security operation.		security service as part of a security operation.
	2. Design Decisions		2. Design Decisions
	The application of security services in a DTN is a complex endeavor		The application of security services in a DTN is a complex endeavor
	that must consider physical properties of the network, policies at		that must consider physical properties of the network (such as
	each node, application security requirements, and current and future		connectivity and propagation times), policies at each node,
	threat environments. This section identifies those desirable		application security requirements, and current and future threat
	properties that guide design decisions for this specification and are		environments. This section identifies those desirable properties
	necessary for understanding the format and behavior of the BPSec		that guide design decisions for this specification and are necessary
	protocol.		for understanding the format and behavior of the BPSec protocol.
	2.1. Block-Level Granularity		2.1. Block-Level Granularity
	Security services within this specification must allow different		Security services within this specification must allow different
	blocks within a bundle to have different security services applied to		blocks within a bundle to have different security services applied to
	them.		them.
	Blocks within a bundle represent different types of information. The		Blocks within a bundle represent different types of information. The
	primary block contains identification and routing information. The		primary block contains identification and routing information. The
	payload block carries application data. Extension blocks carry a		payload block carries application data. Extension blocks carry a
	skipping to change at page 8, line 33 ¶		skipping to change at page 8, line 37 ¶
	consistent with its security policy.		consistent with its security policy.
	When a waypoint adds a security service to the bundle, the waypoint		When a waypoint adds a security service to the bundle, the waypoint
	is the security source for that service. The security block(s) which		is the security source for that service. The security block(s) which
	represent that service in the bundle may need to record this security		represent that service in the bundle may need to record this security
	source as the bundle destination might need this information for		source as the bundle destination might need this information for
	processing.		processing.
	For example, a bundle source may choose to apply an integrity service		For example, a bundle source may choose to apply an integrity service
	to its plain text payload. Later a waypoint node, representing a		to its plain text payload. Later a waypoint node, representing a
	gateway to an insecure portion of the DTN, may receive the bundle and		gateway to another portion of the DTN, may receive the bundle and
	choose to apply a confidentiality service. In this case, the		choose to apply a confidentiality service. In this case, the
	integrity security source is the bundle source and the		integrity security source is the bundle source and the
	confidentiality security source is the waypoint node.		confidentiality security source is the waypoint node.
			In cases where the security source and security acceptor are not the
			bundle source and bundle destination, it is possible that the bundle
			will reach the bundle destination prior to reaching a security
			acceptor. In cases where this may be a practical problem, it is
			recommended that solutions such as bundle encapsulation can be used
			to ensure that a bundle be delivered to a security acceptor prior to
			being delivered to the bundle destination. Generally, if a bundle
			reaches a waypoint that has the appropriate configuration and policy
			to act as a security acceptor for a security service in the bundle,
			then the waypoint should act as that security acceptor.
	2.3. Mixed Security Policy		2.3. Mixed Security Policy
	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
	skipping to change at page 10, line 30 ¶		skipping to change at page 10, line 49 ¶
	3.2. Uniqueness		3.2. Uniqueness
	Security operations in a bundle MUST be unique; the same security		Security operations in a bundle MUST be unique; the same security
	service MUST NOT be applied to a security target more than once in a		service MUST NOT be applied to a security target more than once in a
	bundle. Since a security operation is represented as a security		bundle. Since a security operation is represented as a security
	block, this limits what security blocks may be added to a bundle: if		block, this limits what security blocks may be added to a bundle: if
	adding a security block to a bundle would cause some other security		adding a security block to a bundle would cause some other security
	block to no longer represent a unique security operation then the new		block to no longer represent a unique security operation then the new
	block MUST NOT be added.		block MUST NOT be added.
			The uniqueness requirement imposed by this specification implies that
			the security source for some security target is providing the initial
			service for that target. This is the case when the security source
			is also the source of the target. This can also occur when the
			security source is adding the service to a pre-existing target for
			the first time. If more complex security combinations are required,
			this specification allows for the definition of custom security
			contexts (Section 9) and other security blocks (Section 10).
	A security operation may be removed from a bundle as part of		A security operation may be removed from a bundle as part of
	processing a security block and, once removed, the same security		processing a security block and, once removed, the same security
	operation may be re-applied by adding a new security block into the		operation may be re-applied by adding a new security block into the
	bundle. In this case, conflicting security blocks never co-exist in		bundle. In this case, conflicting security blocks never co-exist in
	the bundle at the same time.		the bundle at the same time.
	It is important to note that any cipher text integrity mechanism		It is important to note that any cipher text integrity mechanism
	supplied by the BCB is considered part of the confidentiality service		supplied by the BCB is considered part of the confidentiality service
	and, therefore, unique from the plain text integrity service provided		and, therefore, unique from the plain text integrity service provided
	by the BIB.		by the BIB.
	skipping to change at page 13, line 17 ¶		skipping to change at page 13, line 48 ¶
	Security Targets:		Security Targets:
	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. The order of elements in this list has no semantic
			meaning outside of the context of this block. Within the
			block, the ordering of targets must match the ordering of
			results associated with these targets.
	Security Context Id:		Security Context Id:
	This field identifies the security context used to implement		This field identifies the security context used to implement
	the security service represented by this block and applied to		the security service represented by this block and applied to
	each security target. This field SHALL be represented by a		each security target. This field SHALL be represented by a
	CBOR unsigned integer. The values for this Id should come from		CBOR unsigned integer. The values for this Id should come from
	the registry defined in Section 11.2		the registry defined in Section 11.2
	Security Context Flags:		Security Context Flags:
	This field identifies which optional fields are present in the		This field identifies which optional fields are present in the
	skipping to change at page 22, line 44 ¶		skipping to change at page 23, line 44 ¶
	exceptions.		exceptions.
	o If the service being applied is a confidentiality service, then		o If the service being applied is a confidentiality service, then
	the block type code, block number, block processing control flags,		the block type code, block number, block processing control flags,
	CRC type and CRC field (if present), and the length indication of		CRC type and CRC field (if present), and the length indication of
	the block-type-specific-data field MUST NOT be included in a		the block-type-specific-data field MUST NOT be included in a
	canonical form. Confidentiality services are used solely to		canonical form. Confidentiality services are used solely to
	convert block data in the block-type-specific-data field from		convert block data in the block-type-specific-data field from
	plain text to cipher text.		plain text to cipher text.
	o Reserved flags in the block processing control flags field MUST		o Reserved flags in the block processing control flags field MUST be
	NOT be included in a canonical form as it is not known if those		set to 0 in a canonical form as it is not known if those flags
	flags will change in transit.		will change in transit.
	Cipher suites and security contexts MAY define their own		Cipher suites and security contexts MAY define their own
	canonicalization algorithms and require the use of those algorithms		canonicalization algorithms and require the use of those algorithms
	over the ones provided in this specification. In the event of		over the ones provided in this specification. In the event of
	conflicting canonicalization algorithms, those algorithms take		conflicting canonicalization algorithms, those algorithms take
	precedence over this specification.		precedence over this specification.
	5. Security Processing		5. Security Processing
	This section describes the security aspects of bundle processing.		This section describes the security aspects of bundle processing.
	skipping to change at page 31, line 33 ¶		skipping to change at page 32, line 33 ¶
	prevent other activities).		prevent other activities).
	BPSec relies on cipher suite capabilities to prevent replay or forged		BPSec relies on cipher suite capabilities to prevent replay or forged
	message attacks. A BCB used with appropriate cryptographic		message attacks. A BCB used with appropriate cryptographic
	mechanisms may provide replay protection under certain circumstances.		mechanisms may provide replay protection under certain circumstances.
	Alternatively, application data itself may be augmented to include		Alternatively, application data itself may be augmented to include
	mechanisms to assert data uniqueness and then protected with a BIB, a		mechanisms to assert data uniqueness and then protected with a BIB, a
	BCB, or both along with other block data. In such a case, the		BCB, or both along with other block data. In such a case, the
	receiving node would be able to validate the uniqueness of the data.		receiving node would be able to validate the uniqueness of the data.
			For example, a BIB may be used to validate the integrity of a
			bundle's primary block, which includes a timestamp and lifetime for
			the bundle. If a bundle is replayed outside of its lifetime, then
			the replay attack will fail as the bundle will be discarded.
			Similarly, additional blocks such as the Bundle Age may be signed and
			validated to identify replay attacks. Finally, security context
			parameters within BIB and BCB blocks may include anti-replay
			mechanisms such as session identifiers, nonces, and dynamic passwords
			as supported by network characteristics.
	9. Security Context Considerations		9. Security Context Considerations
	9.1. Mandating Security Contexts		9.1. Mandating Security Contexts
	Because of the diversity of networking scenarios and node		Because of the diversity of networking scenarios and node
	capabilities that may utilize BPSec there is no one security context		capabilities that may utilize BPSec there is no one security context
	mandated for every possible BPSec implementation. For example, a		mandated for every possible BPSec implementation. For example, a
	security context appropriate for a resource-constrained node with		security context appropriate for a resource-constrained node with
	limited connectivity may be inappropriate for use in a well-		limited connectivity may be inappropriate for use in a well-
	resourced, well connected node.		resourced, well connected node.
	skipping to change at page 37, line 10 ¶		skipping to change at page 38, line 10 ¶
	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-22 (work in progress),		Version 7", draft-ietf-dtn-bpbis-22 (work in progress),
	February 2020.		February 2020.
			[I-D.ietf-dtn-bpsec-interop-sc]
			Birrane, E., "BPSec Interoperability Security Contexts",
			draft-ietf-dtn-bpsec-interop-sc-01 (work in progress),
			February 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 37, line 40 ¶		skipping to change at page 38, line 45 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	12.2. Informative References		12.2. Informative References
	[I-D.birrane-dtn-sbsp]		[I-D.birrane-dtn-sbsp]
	Birrane, E., Pierce-Mayer, J., and D. Iannicca,		Birrane, E., Pierce-Mayer, J., and D. Iannicca,
	"Streamlined Bundle Security Protocol Specification",		"Streamlined Bundle Security Protocol Specification",
	draft-birrane-dtn-sbsp-01 (work in progress), October		draft-birrane-dtn-sbsp-01 (work in progress), October
	2015.		2015.
	[I-D.ietf-dtn-bpsec-interop-sc]
	Birrane, E., "BPSec Interoperability Security Contexts",
	draft-ietf-dtn-bpsec-interop-sc-01 (work in progress),
	February 2020.
	[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,		[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
	R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant		R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
	Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,		Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
	April 2007, <https://www.rfc-editor.org/info/rfc4838>.		April 2007, <https://www.rfc-editor.org/info/rfc4838>.
	[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,		[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
	"Bundle Security Protocol Specification", RFC 6257,		"Bundle Security Protocol Specification", RFC 6257,
	DOI 10.17487/RFC6257, May 2011,		DOI 10.17487/RFC6257, May 2011,
	<https://www.rfc-editor.org/info/rfc6257>.		<https://www.rfc-editor.org/info/rfc6257>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The following participants contributed technical material, use cases,		The following participants contributed technical material, use cases,
	and useful thoughts on the overall approach to this security		and useful thoughts on the overall approach to this security
	specification: Scott Burleigh of the Jet Propulsion Laboratory, Amy		specification: Scott Burleigh of the Jet Propulsion Laboratory,
	Alford and Angela Hennessy of the Laboratory for Telecommunications		Angela Hennessy of the Laboratory for Telecommunications Sciences,
	Sciences, and Angela Dalton and Cherita Corbett of the Johns Hopkins		and Amy Alford, Angela Dalton, and Cherita Corbett of the Johns
	University Applied Physics Laboratory.		Hopkins 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
End of changes. 18 change blocks.
	85 lines changed or deleted		119 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/