draft-ietf-dtn-bpsec-09.txt		draft-ietf-dtn-bpsec-10.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 25, 2019 February 21, 2019		Expires: October 11, 2019 April 9, 2019
	Bundle Protocol Security Specification		Bundle Protocol Security Specification
	draft-ietf-dtn-bpsec-09		draft-ietf-dtn-bpsec-10
	Abstract		Abstract
	This document defines a security protocol providing end to end data		This document defines a security protocol providing end to end data
	integrity and confidentiality services for the Bundle Protocol.		integrity and confidentiality services for the Bundle Protocol.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 25, 2019.		This Internet-Draft will expire on October 11, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 25 ¶		skipping to change at page 2, line 25 ¶
	2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8		2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8
	2.4. User-Defined Security Contexts . . . . . . . . . . . . . 8		2.4. User-Defined Security Contexts . . . . . . . . . . . . . 8
	2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9		2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9
	3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9		3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9		3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9
	3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9		3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9
	3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10		3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10
	3.4. Target Identification . . . . . . . . . . . . . . . . . . 11		3.4. Target Identification . . . . . . . . . . . . . . . . . . 11
	3.5. Block Representation . . . . . . . . . . . . . . . . . . 11		3.5. Block Representation . . . . . . . . . . . . . . . . . . 11
	3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12		3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12
	3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 14		3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15
	3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 15		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 . . . . . . . . . . . . . . . . . . . 18		3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 18
	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 . . . . . . . . . . . . . . . . . . . . . . . 21		4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 21
	5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22		5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22
	5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 22		5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 22
	5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 22		5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 22
	5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 23		5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 23
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 45 ¶
	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.
	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 target data within a bundle are not		Integrity services ensure that changes to target data within a
	changed from the time they are provided to the network to the time		bundle, if any, can be discovered. Data changes may be caused by
	they are delivered at their destination. Data changes may be caused		processing errors, environmental conditions, or intentional
	by processing errors, environmental conditions, or intentional
	manipulation. In the context of BPSec, integrity services apply to		manipulation. In the context of BPSec, integrity services apply to
	plain-text in the bundle.		plain-text in the bundle.
	Confidentiality services ensure that target data is unintelligible to		Confidentiality services ensure that target data is unintelligible to
	nodes in the DTN, except for authorized nodes possessing special		nodes in the DTN, except for authorized nodes possessing special
	information. This generally means producing cipher-text from plain-		information. This generally means producing cipher-text from plain-
	text and generating authentication information for that cipher-text.		text and generating authentication information for that cipher-text.
	Confidentiality, in this context, applies to the contents of target		Confidentiality, in this context, applies to the contents of target
	data and does not extend to hiding the fact that confidentiality		data and does not extend to hiding the fact that confidentiality
	exists in the bundle.		exists in the bundle.
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 44 ¶
	"Delay-Tolerant Networking Architecture" [RFC4838] defines the		"Delay-Tolerant Networking Architecture" [RFC4838] defines the
	architecture for DTNs and identifies certain security assumptions		architecture for DTNs and identifies certain security assumptions
	made by existing Internet protocols that are not valid in a DTN.		made by existing Internet protocols that are not valid in a DTN.
	The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and		The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and
	processing of bundles, defines the extension block format used to		processing of bundles, defines the extension block format used to
	represent BPSec security blocks, and defines the canonicalization		represent BPSec security blocks, and defines the canonicalization
	algorithms used by this specification.		algorithms used by this specification.
			The Concise Binary Object Representation (CBOR) format [RFC7049]
			defines a data format that allows for small code size, fairly small
			message size, and extensibility without version negotiation. The
			block-specific data associated with BPSec security blocks are encoded
			in this data format.
	The Bundle Security Protocol [RFC6257] and Streamlined Bundle		The Bundle Security Protocol [RFC6257] and Streamlined Bundle
	Security Protocol [I-D.birrane-dtn-sbsp] documents introduced the		Security Protocol [I-D.birrane-dtn-sbsp] documents introduced the
	concepts of using BP extension blocks for security services in a DTN.		concepts of using BP extension blocks for security services in a DTN.
	The BPSec is a continuation and refinement of these documents.		The BPSec is a continuation and refinement of these documents.
	1.4. Terminology		1.4. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	skipping to change at page 18, line 14 ¶		skipping to change at page 18, line 22 ¶
	These restrictions on block interactions impose a necessary ordering		These restrictions on block interactions impose a necessary ordering
	when applying security operations within a bundle. Specifically, for		when applying security operations within a bundle. Specifically, for
	a given security target, BIBs MUST be added before BCBs. This		a given security target, BIBs MUST be added before BCBs. This
	ordering MUST be preserved in cases where the current BPA is adding		ordering MUST be preserved in cases where the current BPA is adding
	all of the security blocks for the bundle or whether the BPA is a		all of the security blocks for the bundle or whether the BPA is a
	waypoint adding new security blocks to a bundle that already contains		waypoint adding new security blocks to a bundle that already contains
	security blocks.		security blocks.
	NOTE: Since any cipher suite used with a BCB MUST be an AEAD cipher		NOTE: Since any cipher suite used with a BCB MUST be an AEAD cipher
	suite, it is inefficient and possible insecure for a single security		suite, it is inefficient and possibly insecure for a single security
	source to add both a BIB and a BCB for the same security target. In		source to add both a BIB and a BCB for the same security target. In
	cases where a security source wishes to calculate both a plain-text		cases where a security source wishes to calculate both a plain-text
	integrity mechanism and encrypt a security target, a BCB with a		integrity mechanism and encrypt a security target, a BCB with a
	cipher suite that generates such signatures as additional security		cipher suite that generates such signatures as additional security
	results SHOULD be used instead.		results SHOULD be used instead.
	3.10. Parameter and Result Identification		3.10. Parameter and Result Identification
	Security context parameters and results each represent multiple		Security context parameters and results each represent multiple
	distinct pieces of information in a security block. Each piece of		distinct pieces of information in a security block. Each piece of
	skipping to change at page 34, line 19 ¶		skipping to change at page 34, line 19 ¶
	[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>.
	[RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol		[RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol
	IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May		IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May
	2011, <https://www.rfc-editor.org/info/rfc6255>.		2011, <https://www.rfc-editor.org/info/rfc6255>.
			[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
			Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
			October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	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.
	[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
End of changes. 8 change blocks.
	10 lines changed or deleted		19 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/