draft-ietf-i2rs-protocol-security-requirements-00.txt		draft-ietf-i2rs-protocol-security-requirements-01.txt
	I2RS working group S. Hares		I2RS working group S. Hares
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track D. Migault		Intended status: Standards Track D. Migault
	Expires: March 4, 2016 J. Halpern		Expires: March 5, 2016 J. Halpern
	Ericsson		Ericsson
	September 1, 2015		September 2, 2015
	I2RS Security Related Requirements		I2RS Security Related Requirements
	draft-ietf-i2rs-protocol-security-requirements-00		draft-ietf-i2rs-protocol-security-requirements-01
	Abstract		Abstract
	This presents security-related requirements for the I2RS protocol for		This presents security-related requirements for the I2RS protocol for
	mutual authentication, transport protocols, data transfer and		mutual authentication, transport protocols, data transfer and
	transactions.		transactions.
	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
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 March 4, 2016.		This Internet-Draft will expire on March 5, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions used in this document . . . . . . . . . . . . 2		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
	1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Security-Related Requirements . . . . . . . . . . . . . . . . 5		2. Security-Related Requirements . . . . . . . . . . . . . . . . 5
	2.1. Mutual authentication of I2RS client and I2RS Agent . . . 5		2.1. Mutual authentication of I2RS client and I2RS Agent . . . 5
	2.2. Transport Requirements Based on Mutual Authentication . . 6		2.2. Transport Requirements Based on Mutual Authentication . . 6
	2.3. Data Confidentiality Requirements . . . . . . . . . . . . 7		2.3. Data Confidentiality Requirements . . . . . . . . . . . . 7
	2.4. Data Integrity Requirements . . . . . . . . . . . . . . . 7		2.4. Data Integrity Requirements . . . . . . . . . . . . . . . 7
	2.5. Role-Based Data Model Security . . . . . . . . . . . . . 8		2.5. Role-Based Data Model Security . . . . . . . . . . . . . 8
	3. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8		3. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	skipping to change at page 2, line 47		skipping to change at page 2, line 47
	[I-D.haas-i2rs-ephemeral-state-reqs] discusses I2RS roles-based write		[I-D.haas-i2rs-ephemeral-state-reqs] discusses I2RS roles-based write
	conflict resolution in the ephemeral data store using the I2RS Client		conflict resolution in the ephemeral data store using the I2RS Client
	Identity, I2RS Secondary Identity and priority. The draft		Identity, I2RS Secondary Identity and priority. The draft
	[I-D.ietf-i2rs-traceability] describes the traceability framework and		[I-D.ietf-i2rs-traceability] describes the traceability framework and
	its requirements for I2RS. The draft		its requirements for I2RS. The draft
	[I-D.ietf-i2rs-pub-sub-requirements] describes the requirements for		[I-D.ietf-i2rs-pub-sub-requirements] describes the requirements for
	I2RS to be able to publish information or have a remote client		I2RS to be able to publish information or have a remote client
	subscribe to an information data stream.		subscribe to an information data stream.
	1.1. Conventions used in this document		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119]		document are to be interpreted as described in RFC 2119 [RFC2119].
	1.2. Definitions		1.2. Definitions
	This document utilizes the definitions found in the following drafts:		This document utilizes the definitions found in the following drafts:
	[RFC4949], and [I-D.ietf-i2rs-architecture]		[RFC4949], and [I-D.ietf-i2rs-architecture]
	Specifically, this document utilizes the following definitions:		Specifically, this document utilizes the following definitions:
	access control		access control
	skipping to change at page 4, line 24		skipping to change at page 4, line 24
	[RFC4949] describes data privacy as a synonym for data		[RFC4949] describes data privacy as a synonym for data
	confidentiality. This I2RS document will utilize data privacy as		confidentiality. This I2RS document will utilize data privacy as
	a synonym for data confidentiality.		a synonym for data confidentiality.
	Mutual Authentication		Mutual Authentication
	[RFC4949] implies that mutual authentication exists between two		[RFC4949] implies that mutual authentication exists between two
	interacting system entities. Mutual authentication in I2RS		interacting system entities. Mutual authentication in I2RS
	implies that both sides move from a state of mutual suspicion to		implies that both sides move from a state of mutual suspicion to
	mutually authenticated communication afte each system has been		mutually authenticated communication after each system has been
	identified and validated by its peer system.		identified and validated by its peer system.
	role		role
	[RFC4949] describes role as:		[RFC4949] describes role as:
	1) (I) A job function or employment position to which people or		1) (I) A job function or employment position to which people or
	other system entities may be assigned in a system. (See: role-		other system entities may be assigned in a system. (See: role-
	based access control. Compare: duty, billet, principal, user.)		based access control. Compare: duty, billet, principal, user.)
	skipping to change at page 5, line 26		skipping to change at page 5, line 26
	The transfer of data via the I2RS protocol has the property of		The transfer of data via the I2RS protocol has the property of
	data integrity described in [RFC4949].		data integrity described in [RFC4949].
	2. Security-Related Requirements		2. Security-Related Requirements
	The security for the I2RS protocol requires mutually authenticated		The security for the I2RS protocol requires mutually authenticated
	I2RS clients and I2RS agents. The I2RS client and I2RS agent using		I2RS clients and I2RS agents. The I2RS client and I2RS agent using
	the I2RS protocol MUST be able to exchange data over a secure		the I2RS protocol MUST be able to exchange data over a secure
	transport, but some functions may operate on non-secure transport.		transport, but some functions may operate on non-secure transport.
	The I2RS protocol MUST BE able to provide atomicity of a transaction,		The I2RS protocol MUST BE able to provide atomicity of a transaction,
	but it is not required to have multi-message atomicity and rollback		but it is not required to have multi-message atomicity and roll-back
	mechanism transactions. Multiple messages transactions may be		mechanism transactions. Multiple messages transactions may be
	impacted by the interdependency of data. This section discusses		impacted by the interdependency of data. This section discusses
	these details of these security requirements.		these details of these security requirements.
	2.1. Mutual authentication of I2RS client and I2RS Agent		2.1. Mutual authentication of I2RS client and I2RS Agent
	The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following		The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following
	requirements:		requirements:
	o SEC-REQ-01: All I2RS clients and I2RS agents MUST have at least		o SEC-REQ-01: All I2RS clients and I2RS agents MUST have at least
	one unique identifier that uniquely identifies each party.		one unique identifier that uniquely identifies each party.
	o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for		o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for
	mutual identification of the I2RS client and I2RS agent.		mutual identification of the I2RS client and I2RS agent.
	o SEC-REQ-03:An I2RS agent, upon receiving an I2RS message from a		o SEC-REQ-03:An I2RS agent, upon receiving an I2RS message from a
	I2RS client, MUST confirm that the I2RS client has a valid		I2RS client, MUST confirm that the I2RS client has a valid
	identifier.		identifier.
	o SEC-REQ-04: The I2RS client, upon receiving an I2RS message from		o SEC-REQ-04: The I2RS client, upon receiving an I2RS message from
	an I2RS agent, MUST confirm the I2RS agent's identifier .		an I2RS agent, MUST confirm the I2RS agent has a valid identifier
			.
	o SEC-REQ-05: Identifier distribution and the loading of these		o SEC-REQ-05: Identifier distribution and the loading of these
	identifiers into I2RS agent and I2RS Client SHOULD occur outside		identifiers into I2RS agent and I2RS Client SHOULD occur outside
	the I2RS protocol.		the I2RS protocol.
	o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF		o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF
	or private) will distribute or load identifiers so that the I2RS		or private) will distribute or load identifiers so that the I2RS
	client/agent has these identifiers prior to the I2RS protocol		client/agent has these identifiers prior to the I2RS protocol
	establishing a connection between I2RS client and I2RS agent.		establishing a connection between I2RS client and I2RS agent.
	skipping to change at page 6, line 23		skipping to change at page 6, line 27
	identifier during a particular read/write sequence, but the		identifier during a particular read/write sequence, but the
	secondary identifier may vary during the time a connection between		secondary identifier may vary during the time a connection between
	the I2RS client and I2RS agent is active. The variance of the		the I2RS client and I2RS agent is active. The variance of the
	secondary identifier allows the I2RS client to be associated with		secondary identifier allows the I2RS client to be associated with
	multiple applications and pass along an identifier for these		multiple applications and pass along an identifier for these
	applications in the secondary identifier.		applications in the secondary identifier.
	2.2. Transport Requirements Based on Mutual Authentication		2.2. Transport Requirements Based on Mutual Authentication
	SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a		SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
	secure transport and optionally be able to transfer data over a non-		secure transport and optionally MAY be able to transfer data over a
	secure transport. A secure transport MUST provide data		non-secure transport. A secure transport MUST provide data
	confidentiality, data integrity, and replay prevention.		confidentiality, data integrity, and replay prevention.
	Note:The non-secure transport be used for publishing telemetry data		Note:The non-secure transport can be used for publishing telemetry
	that was specifically indicated to non-confidential in the data		data that was specifically indicated to non-confidential in the data
	model. The configuration of ephemeral data in the I2RS Agent by the		model. The configuration of ephemeral data in the I2RS Agent by the
	I2RS client SHOULD be done over a secure transport. It is		I2RS client SHOULD be done over a secure transport. It is
	anticipated that the passing of most I2RS ephemeral state operational		anticipated that the passing of most I2RS ephemeral state operational
	status SHOULD be done over a secure transport. Data models SHOULD		status SHOULD be done over a secure transport. Data models SHOULD
	clearly annotate what data nodes can be passed over an insecure		clearly annotate what data nodes can be passed over an insecure
	connection. The default transport is a secure transport.		connection. The default transport is a secure transport.
	SEC-REQ-10: A secure transport MUST be associated with a key		SEC-REQ-10: A secure transport MUST be associated with a key
	management solution that can guarantee that only the entities having		management solution that can guarantee that only the entities having
	sufficient privileges can get the keys to encrypt/decrypt the		sufficient privileges can get the keys to encrypt/decrypt the
	skipping to change at page 6, line 49		skipping to change at page 7, line 4
	sensitive data. Per BCP107 [RFC4107] this key management system		sensitive data. Per BCP107 [RFC4107] this key management system
	SHOULD be automatic, but MAY BE manual if the following constraints		SHOULD be automatic, but MAY BE manual if the following constraints
	from BCP107:		from BCP107:
	a)environment has limited bandwidth or high round-trip times,		a)environment has limited bandwidth or high round-trip times,
	b)the information being protected has a low value and		b)the information being protected has a low value and
	c)the total volume over the entire lifetime of the long-term		c)the total volume over the entire lifetime of the long-term
	session key will be very low,		session key will be very low,
	d)the scale of the deployment is limited.		d)the scale of the deployment is limited.
	Most I2RS environments (I2RS Client - I2S Agents) will not have this		Most I2RS environments (I2RS Client - I2S Agents) will not have the
	environment, but a few I2RS use case provide limited non-secure		environment described by BCP107 [RFC4107] but a few I2RS use cases
	light-weight telemetry messages that have these requirements. An		required limited non-secure light-weight telemetry messages that have
	I2RS data model must indicate which portions can be served by manual		these requirements. An I2RS data model must indicate which portions
	key management.		can be served by manual key management.
	SEC-REQ-11: The I2RS protocol MUST be able to support multiple secure		SEC-REQ-11: The I2RS protocol MUST be able to support multiple secure
	transport sessions providing protocol and data communication between		transport sessions providing protocol and data communication between
	an I2RS Agent and an I2RS client. However, a single I2RS Agent to		an I2RS Agent and an I2RS client. However, a single I2RS Agent to
	I2RS client connection MAY elect to use a single secure transport		I2RS client connection MAY elect to use a single secure transport
	session or a single non-secure transport session.		session or a single non-secure transport session.
	SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement		SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement
	mechanisms that mitigate DoS attacks		mechanisms that mitigate DoS attacks
	skipping to change at page 8, line 7		skipping to change at page 8, line 8
	replay attack		replay attack
	Requirements SEC-REQ-13 and SEC-REQ-14 are SHOULD requirements only		Requirements SEC-REQ-13 and SEC-REQ-14 are SHOULD requirements only
	because it is recognized that some I2RS Client to I2RS agent		because it is recognized that some I2RS Client to I2RS agent
	communication occurs over a non-secure channel. The I2RS client to		communication occurs over a non-secure channel. The I2RS client to
	I2RS agent over a secure channel would implement these features. In		I2RS agent over a secure channel would implement these features. In
	order to provide some traceability or notification for the non-secure		order to provide some traceability or notification for the non-secure
	protocol, SEC-REQ-16 suggests traceability and notification are		protocol, SEC-REQ-16 suggests traceability and notification are
	important to include for any non-secure protocol.		important to include for any non-secure protocol.
	SEC-REQ-17: The I2RS message traceability and notification		SEC-REQ-16: The I2RS message traceability and notification
	requirements requirements found in [I-D.ietf-i2rs-traceability] and		requirements requirements found in [I-D.ietf-i2rs-traceability] and
	[I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in		[I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in
	communication channel that is non-secure to trace or notify about		communication channel that is non-secure to trace or notify about
	potential security issues		potential security issues
	2.5. Role-Based Data Model Security		2.5. Role-Based Data Model Security
	The [I-D.ietf-i2rs-architecture] defines a role or security role as		The [I-D.ietf-i2rs-architecture] defines a role or security role as
	specifying read, write, or notification access by a I2RS client to		specifying read, write, or notification access by a I2RS client to
	data within an agent's data model.		data within an agent's data model.
	SEC-REQ-18: The rules around what role is permitted to access and		SEC-REQ-17: The rules around what role is permitted to access and
	manipulate what information plus a secure transport (which protects		manipulate what information plus a secure transport (which protects
	the data in transit) SHOULD ensure that data of any level of		the data in transit) SHOULD ensure that data of any level of
	sensitivity is reasonably protected from being observed by those		sensitivity is reasonably protected from being observed by those
	without permission to view it, so that privacy requirements are met.		without permission to view it, so that privacy requirements are met.
	SEC-REQ-19: Role security MUST work when multiple transport		SEC-REQ-18: Role security MUST work when multiple transport
	connections are being used between the I2RS client and I2RS agent as		connections are being used between the I2RS client and I2RS agent as
	the I2RS architecture [I-D.ietf-i2rs-architecture] states. These		the I2RS architecture [I-D.ietf-i2rs-architecture] states. These
	transport message streams may start/stop without affecting the		transport message streams may start/stop without affecting the
	existence of the client/agent data exchange. TCP supports a single		existence of the client/agent data exchange. TCP supports a single
	stream of data. SCTP [RFC4960] provides security for multiple		stream of data. SCTP [RFC4960] provides security for multiple
	streams plus end-to-end transport of data.		streams plus end-to-end transport of data.
	SEC-REQ-20: I2RS clients MAY be used by multiple applications to		SEC-REQ-19: I2RS clients MAY be used by multiple applications to
	configure routing via I2RS agents, receive status reports, turn on		configure routing via I2RS agents, receive status reports, turn on
	the I2RS audit stream, or turn on I2RS traceability. Application		the I2RS audit stream, or turn on I2RS traceability. Application
	software using I2RS client functions may host several multiple secure		software using I2RS client functions may host several multiple secure
	identities, but each connection will use only one identifier with one		identities, but each connection will use only one identifier with one
	priority. Therefore, the security of each I2RS Client to I2RS Agent		priority. Therefore, the security of each I2RS Client to I2RS Agent
	connection is unique.		connection is unique.
	Please note the security of the application to I2RS client connection		Please note the security of the application to I2RS client connection
	is outside of the I2RS protocol or I2RS interface.		is outside of the I2RS protocol or I2RS interface.
End of changes. 18 change blocks.
	24 lines changed or deleted		24 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/