draft-ietf-dtn-bpsec-19.txt		draft-ietf-dtn-bpsec-20.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: August 10, 2020 February 7, 2020
	Bundle Protocol Security Specification		Bundle Protocol Security Specification
	draft-ietf-dtn-bpsec-19		draft-ietf-dtn-bpsec-20
	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 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	3.4. Target Identification . . . . . . . . . . . . . . . . . . 12		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 . . . . . . . . . . . . . . . . . . . . . . . 20		4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22
	5. Security Processing . . . . . . . . . . . . . . . . . . . . . 21		5. Security Processing . . . . . . . . . . . . . . . . . . . . . 23
	5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 22		5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23
	5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 22		5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23
	5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 23		5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24
	5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 24		5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 25
	6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 24		6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 25
	7. Security Policy Considerations . . . . . . . . . . . . . . . 24		7. Security Policy Considerations . . . . . . . . . . . . . . . 25
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 26		8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	8.1. Attacker Capabilities and Objectives . . . . . . . . . . 26		8.1. Attacker Capabilities and Objectives . . . . . . . . . . 27
	8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 27		8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 28
	8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 27		8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 28
	8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 28		8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29
	8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 29		8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30
	8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 30		8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 31
	9. Security Context Considerations . . . . . . . . . . . . . . . 30		9. Security Context Considerations . . . . . . . . . . . . . . . 31
	9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 30		9.1. Mandating Security Contexts . . . . . . . . . . . . . . . 31
	9.2. Identification and Configuration . . . . . . . . . . . . 31		9.2. Identification and Configuration . . . . . . . . . . . . 32
	9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 32		9.3. Authorship . . . . . . . . . . . . . . . . . . . . . . . 33
	10. Defining Other Security Blocks . . . . . . . . . . . . . . . 33		10. Defining Other Security Blocks . . . . . . . . . . . . . . . 34
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 34		11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 36
	11.2. Security Context Identifiers . . . . . . . . . . . . . . 35		11.2. Security Context Identifiers . . . . . . . . . . . . . . 36
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
	12.1. Normative References . . . . . . . . . . . . . . . . . . 35		12.1. Normative References . . . . . . . . . . . . . . . . . . 36
	12.2. Informative References . . . . . . . . . . . . . . . . . 36		12.2. Informative References . . . . . . . . . . . . . . . . . 37
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	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.
	skipping to change at page 14, line 32 ¶		skipping to change at page 14, line 32 ¶
	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 23 ¶		skipping to change at page 15, line 28 ¶
	* 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.
	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-type-specific-data field follows the structure of the		The block-type-specific-data field follows the structure of the
	ASB.		ASB.
	skipping to change at page 19, line 27 ¶		skipping to change at page 19, line 33 ¶
	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 canonical form of the		o An integrity signature applied to the canonical form of the
	primary block (B1), the canonical form of the block-type-specific-		primary block (B1), the canonical form of the block-type-specific-
	data field of the second extension block (B5) and the canonical		data field of the second extension block (B5) and the canonical
	form of the payload block (B6). This is accomplished by a single		form of the payload block (B6). This is accomplished by a single
	BIB (B2) with multiple targets. A single BIB is used in this case		BIB (B2) with multiple targets. A single BIB is used in this case
	skipping to change at page 20, line 19 ¶		skipping to change at page 21, line 5 ¶
	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 the block-type-specific-		o Since the waypoint node wishes to encrypt the block-type-specific-
	data field of blocks B5 and B6, it MUST also encrypt the block-		data field of blocks B5 and B6, it MUST also encrypt the block-
	type-specific-data field of the BIBs providing plain text		type-specific-data field of the BIBs providing plain text
	integrity over those blocks. However, BIB B2 could not be		integrity over those blocks. However, BIB B2 could not be
	encrypted in its entirety because it also held a signature for the		encrypted in its entirety because it also held a signature for the
	skipping to change at page 31, line 42 ¶		skipping to change at page 33, line 16 ¶
	+---------+------------+--------------------------------------------+		+---------+------------+--------------------------------------------+
	| Context | Parameters | Definition |		| Context | Parameters | Definition |
	| Id | | |		| Id | | |
	+---------+------------+--------------------------------------------+		+---------+------------+--------------------------------------------+
	| 1 | Encrypted | AES-GCM-256 cipher suite with provided |		| 1 | Encrypted | AES-GCM-256 cipher suite with provided |
	| | Key, IV | ephemeral key encrypted with a |		| | Key, IV | ephemeral key encrypted with a |
	| | | predetermined key encryption key and clear |		| | | predetermined key encryption key and clear |
	| | | text initialization vector. |		| | | text initialization vector. |
	| 2 | IV | AES-GCM-256 cipher suite with |		| 2 | IV | AES-GCM-256 cipher suite with |
	| | | predetermined key and predetermined |		| | | predetermined key and predetermined key |
	| | | key rotation policy. |		| | | 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.3. Authorship		9.3. Authorship
	Developers or implementers should consider the diverse performance		Developers or implementers should consider the diverse performance
	and conditions of networks on which the Bundle Protocol (and		and conditions of networks on which the Bundle Protocol (and
	skipping to change at page 36, line 44 ¶		skipping to change at page 38, line 22 ¶
	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		The Johns Hopkins University Applied Physics Laboratory
	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		The Johns Hopkins University Applied Physics Laboratory
	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. 10 change blocks.
	35 lines changed or deleted		88 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/