draft-ietf-i2rs-protocol-security-requirements-16.txt		draft-ietf-i2rs-protocol-security-requirements-17.txt
	I2RS working group S. Hares		I2RS working group S. Hares
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Informational D. Migault		Intended status: Informational D. Migault
	Expires: April 2, 2017 J. Halpern		Expires: April 2, 2017 J. Halpern
	Ericsson		Ericsson
	September 29, 2016		September 29, 2016
	I2RS Security Related Requirements		I2RS Security Related Requirements
	draft-ietf-i2rs-protocol-security-requirements-16		draft-ietf-i2rs-protocol-security-requirements-17
	Abstract		Abstract
	This presents security-related requirements for the I2RS protocol		This presents security-related requirements for the I2RS protocol
	which provides a new interface to the routing system described in the		which provides a new interface to the routing system described in the
	I2RS architecture document (RFC7921). The I2RS protocol is a re-use		I2RS architecture document (RFC7921). The I2RS protocol is a re-use
	protocol implemented by re-using portions of existing IETF protocols		protocol implemented by re-using portions of existing IETF protocols
	and adding new features to these protocols. The I2RS protocol re-		and adding new features to these protocols. The I2RS protocol re-
	uses security features of a secure transport (E.g. TLS, SSH, DTLS)		uses security features of a secure transport (E.g. TLS, SSH, DTLS)
	such as encryption, message integrity, mutual peer authentication,		such as encryption, message integrity, mutual peer authentication,
	skipping to change at page 10, line 39 ¶		skipping to change at page 10, line 39 ¶
	o role-based security (section 4.6),		o role-based security (section 4.6),
	o security environment (section 4.7)		o security environment (section 4.7)
	The I2RS Protocol depends upon a secure transport layer for peer		The I2RS Protocol depends upon a secure transport layer for peer
	authentication, data integrity, confidentiality, and replay		authentication, data integrity, confidentiality, and replay
	protection. The optional insecure transport can only be used		protection. The optional insecure transport can only be used
	restricted set of publically data available (events or information)		restricted set of publically data available (events or information)
	or a select set of legacy data. Data passed over the insecure		or a select set of legacy data. Data passed over the insecure
	transport channel MUST NOT contain any data which identifies a person		transport channel MUST NOT contain any data which identifies a
	or any "write" transactions.		person.
	4.1. I2RS Peers(agent and client) Identity Authentication		4.1. I2RS Peers(agent and client) Identity Authentication
	The following requirements specify the security requirements for Peer		The following requirements specify the security requirements for Peer
	Identity Authentication for the I2RS protocol:		Identity Authentication for the I2RS protocol:
	o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an		o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an
	identity, and at least one unique identifier that uniquely		identity, and at least one unique identifier that uniquely
	identifies each party in the I2RS protocol context.		identifies each party in the I2RS protocol context.
	skipping to change at page 11, line 19 ¶		skipping to change at page 11, line 19 ¶
	identifiers into I2RS agent and I2RS client SHOULD occur outside		identifiers into I2RS agent and I2RS client SHOULD occur outside
	the I2RS protocol prior to the I2RS protocol establishing a		the I2RS protocol prior to the I2RS protocol establishing a
	connection between I2RS client and I2RS agent. AAA protocols MAY		connection between I2RS client and I2RS agent. AAA protocols MAY
	be used to distribute these identifiers, but other mechanism can		be used to distribute these identifiers, but other mechanism can
	be used.		be used.
	Explanation:		Explanation:
	These requirements specify the requirements for I2RS peer (I2RS agent		These requirements specify the requirements for I2RS peer (I2RS agent
	and I2RS client) authentication. A secure transport (E.g. TLS) will		and I2RS client) authentication. A secure transport (E.g. TLS) will
	authenticate based on these identities. The AAA protocol		authenticate based on these identities, but these identities are
			identities for the I2RS management layer. An AAA protocol
	distributing I2RS identity information SHOULD transport its		distributing I2RS identity information SHOULD transport its
	information over a secure transport.		information over a secure transport.
	4.2. Identity Validation Before Role-Based Message Actions		4.2. Identity Validation Before Role-Based Message Actions
	The requirements for I2RS clients with Secure Connections are the		The requirements for I2RS clients with Secure Connections are the
	following:		following:
	SEC-REQ-04: An I2RS agent receiving a request from an I2RS client		SEC-REQ-04: An I2RS agent receiving a request from an I2RS client
	MUST confirm that the I2RS client has a valid identity.		MUST confirm that the I2RS client has a valid identity.
	skipping to change at page 12, line 8 ¶		skipping to change at page 12, line 9 ¶
	message is processed rather than checking if a transport session		message is processed rather than checking if a transport session
	exists.		exists.
	During the time period when a secure transport session is active, the		During the time period when a secure transport session is active, the
	I2RS agent SHOULD assume that the I2RS client's identity remains		I2RS agent SHOULD assume that the I2RS client's identity remains
	valid. Similarly, while a secure connection exists that included		valid. Similarly, while a secure connection exists that included
	validating the I2RS agent's identity and a message is received via		validating the I2RS agent's identity and a message is received via
	that connection, the I2RS client SHOULD assume that the I2RS agent's		that connection, the I2RS client SHOULD assume that the I2RS agent's
	identity remains valid.		identity remains valid.
			The definition of what constitutes a valid identity or a valid
			identifier MUST be defined by the I2RS protocol.
	4.3. Peer Identity, Priority, and Client Redundancy		4.3. Peer Identity, Priority, and Client Redundancy
	Requirements:		Requirements:
	SEC-REQ-07: Each I2RS Identifier MUST be associated with just one		SEC-REQ-07: Each I2RS Identifier MUST be associated with just one
	priority.		priority.
	SEC-REQ-08: Each Identifier is associated with one secondary		SEC-REQ-08: Each Identifier is associated with one secondary
	identifier during a particular I2RS transaction (e.g. read/write		identifier during a particular I2RS transaction (e.g. read/write
	sequence), but the secondary identifier may vary during the time a		sequence), but the secondary identifier may vary during the time a
	skipping to change at page 16, line 35 ¶		skipping to change at page 16, line 37 ¶
	protocol (e.g NETCONF) requires access control (NACM [RFC6536]) for		protocol (e.g NETCONF) requires access control (NACM [RFC6536]) for
	sensitive data needs to be provided; and the confidentiality		sensitive data needs to be provided; and the confidentiality
	protection on such data during transportation needs to be enforced.		protection on such data during transportation needs to be enforced.
	Integrity of data is important even if the I2RS protocol is sending		Integrity of data is important even if the I2RS protocol is sending
	non-confidential data over an insecure connection. The ability to		non-confidential data over an insecure connection. The ability to
	trace I2RS protocol messages that enact I2RS transactions provides a		trace I2RS protocol messages that enact I2RS transactions provides a
	minimal aid to helping operators check how messages enact		minimal aid to helping operators check how messages enact
	transactions on a secure or insecure transport. Contextual checks on		transactions on a secure or insecure transport. Contextual checks on
	specific non-confidential data sent over a insecure connection may		specific non-confidential data sent over a insecure connection may
	indicate the data integrity is questionable.		indicate the data has been modified.
	4.6. Role-Based Data Model Security		4.6. Role-Based Data Model Security
	The I2RS Architecture [RFC7921] specifies access control by "role"		The I2RS Architecture [RFC7921] specifies access control by "role"
	where role is a method of making access control more manageable by		where role is a method of making access control more manageable by
	creating a grouping of users so that access control can be specified		creating a grouping of users so that access control can be specified
	for a role rather than for each of the individuals. Therefore, I2RS		for a role rather than for each of the individuals. Therefore, I2RS
	role specifies the access control for a group as being read, write,		role specifies the access control for a group as being read, write,
	or notification.		or notification.
End of changes. 5 change blocks.
	5 lines changed or deleted		9 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/