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/