draft-ietf-dtn-bpsec-16.txt		draft-ietf-dtn-bpsec-17.txt
	Delay-Tolerant Networking E. Birrane		Delay-Tolerant Networking E. Birrane
	Internet-Draft K. McKeever		Internet-Draft K. McKeever
	Obsoletes: 6257 (if approved) JHU/APL		Obsoletes: 6257 (if approved) JHU/APL
	Intended status: Standards Track January 21, 2020		Intended status: Standards Track January 22, 2020
	Expires: July 24, 2020		Expires: July 25, 2020
	Bundle Protocol Security Specification		Bundle Protocol Security Specification
	draft-ietf-dtn-bpsec-16		draft-ietf-dtn-bpsec-17
	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.
	This document is an update of the protocol described in RFC 6257,		This document is an update of the protocol described in RFC 6257,
	reflecting lessons learned. For this reason it obsoletes RFC 6257,		reflecting lessons learned. For this reason it obsoletes RFC 6257,
	an IRTF-stream document.		an IRTF-stream document.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 July 24, 2020.		This Internet-Draft will expire on July 25, 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 30 ¶		skipping to change at page 2, line 30 ¶
	3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10		3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 10
	3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 10		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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 19
	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 . . . . . . . . . . . . 21		5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23
	5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 21		5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23
	5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 22		5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24
	5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 23		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 . . . . . . . . . . . . . . . . . . . 25		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 . . . . . . . . . . . . . . . . 27		8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29
	8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 28		8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30
	8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 29		8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 30
	9. Security Context Considerations . . . . . . . . . . . . . . . 29		9. Security Context Considerations . . . . . . . . . . . . . . . 31
	9.1. Identification and Configuration . . . . . . . . . . . . 29		9.1. Identification and Configuration . . . . . . . . . . . . 31
	9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 30		9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 32
	10. Defining Other Security Blocks . . . . . . . . . . . . . . . 32		10. Defining Other Security Blocks . . . . . . . . . . . . . . . 33
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 33		11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 34
	11.2. Security Context Identifiers . . . . . . . . . . . . . . 33		11.2. Security Context Identifiers . . . . . . . . . . . . . . 35
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
	12.1. Normative References . . . . . . . . . . . . . . . . . . 34		12.1. Normative References . . . . . . . . . . . . . . . . . . 35
	12.2. Informative References . . . . . . . . . . . . . . . . . 34		12.2. Informative References . . . . . . . . . . . . . . . . . 36
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	1. Introduction		1. Introduction
	This document defines security features for the Bundle Protocol (BP)		This document defines security features for the Bundle Protocol (BP)
	[I-D.ietf-dtn-bpbis] and is intended for use in Delay Tolerant		[I-D.ietf-dtn-bpbis] and is intended for use in Delay Tolerant
	Networks (DTNs) to provide end-to-end security services.		Networks (DTNs) to provide end-to-end security services.
	The Bundle Protocol specification [I-D.ietf-dtn-bpbis] defines DTN as		The Bundle Protocol specification [I-D.ietf-dtn-bpbis] defines DTN as
	referring to "a networking architecture providing communications in		referring to "a networking architecture providing communications in
	and/or through highly stressed environments" where "BP may be viewed		and/or through highly stressed environments" where "BP may be viewed
	skipping to change at page 14, line 31 ¶		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 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.
	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.
	skipping to change at page 19, line 27 ¶		skipping to change at page 20, line 5 ¶
	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 20, line 19 ¶		skipping to change at page 21, line 11 ¶
	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 30, line 24 ¶		skipping to change at page 32, line 12 ¶
	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 |		| | | ephemeral key and initialization vector. |
	| | | 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.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 35, line 17 ¶		skipping to change at page 37, line 8 ¶
	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. 14 change blocks.
	40 lines changed or deleted		91 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/