draft-ietf-i2rs-protocol-security-requirements-06.txt   draft-ietf-i2rs-protocol-security-requirements-07.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: November 25, 2016 J. Halpern Expires: February 17, 2017 J. Halpern
Ericsson Ericsson
May 24, 2016 August 16, 2016
I2RS Security Related Requirements I2RS Security Related Requirements
draft-ietf-i2rs-protocol-security-requirements-06 draft-ietf-i2rs-protocol-security-requirements-07
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 November 25, 2016. This Internet-Draft will expire on February 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
The Interface to the Routing System (I2RS) provides read and write The Interface to the Routing System (I2RS) provides read and write
access to information and state within the routing process. An I2RS access to information and state within the routing process. An I2RS
client interacts with one or more I2RS agents to collect information client interacts with one or more I2RS agents to collect information
from network routing systems. from network routing systems.
This document describes the requirements for the I2RS protocol in the This document describes the requirements for the I2RS protocol in the
security-related areas of mutual authentication of the I2RS client security-related areas of mutual authentication of the I2RS client
and agent, the transport protocol carrying the I2RS protocol and agent, the transport protocol carrying the I2RS protocol
messages, and the atomicity of the transactions. These requirements messages, and the atomicity of the transactions. These requirements
align with the description of the I2RS architecture found in align with the description of the I2RS architecture found in
[I-D.ietf-i2rs-architecture] document which solves the problem [RFC7921] document which solves the problem described in [RFC7920].
described in [I-D.ietf-i2rs-problem-statement].
[I-D.ietf-i2rs-ephemeral-state] discusses I2RS role-based access [I-D.ietf-i2rs-ephemeral-state] discusses I2RS role-based access
control that provides write conflict resolution in the ephemeral data control that provides write conflict resolution in the ephemeral data
store using the I2RS Client Identity, I2RS Secondary Identity and store using the I2RS Client Identity, I2RS Secondary Identity and
priority. The draft [I-D.ietf-i2rs-traceability] describes the priority. The draft [RFC7922] describes the traceability framework
traceability framework and its requirements for I2RS. The draft and its requirements for I2RS. The draft [RFC7923] describes the
[I-D.ietf-i2rs-pub-sub-requirements] describes the requirements for requirements for I2RS to be able to publish information or have a
I2RS to be able to publish information or have a remote client remote client subscribe to an information data stream.
subscribe to an information data stream.
1.1. Requirements Language 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Definitions 2. Definitions
2.1. Security Definitions 2.1. Security Definitions
This document utilizes the definitions found in the following This document utilizes the definitions found in the following
documents: [RFC4949] and [I-D.ietf-i2rs-architecture] documents: [RFC4949] and [RFC7921]
Specifically, this document utilizes the following definitions: Specifically, this document utilizes the following definitions:
access control access control
[RFC4949] defines access control as the following: [RFC4949] defines access control as the following:
1. (I) Protection of system resources against unauthorized 1. (I) Protection of system resources against unauthorized
access. access.
skipping to change at page 3, line 39 skipping to change at page 3, line 39
authorized entities (users, programs, processes, or other authorized entities (users, programs, processes, or other
systems) according to that policy. (See: access, access systems) according to that policy. (See: access, access
control service, computer security, discretionary access control service, computer security, discretionary access
control, mandatory access control, role-based access control.) control, mandatory access control, role-based access control.)
3. (I) /formal model/ Limitations on interactions between 3. (I) /formal model/ Limitations on interactions between
subjects and objects in an information system. subjects and objects in an information system.
4. (O) "The prevention of unauthorized use of a resource, 4. (O) "The prevention of unauthorized use of a resource,
including the prevention of use of a resource in an including the prevention of use of a resource in an
unauthorized manner." [I7498-2] unauthorized manner."
5. (O) /U.S. Government/ A system using physical, electronic, 5. (O) /U.S. Government/ A system using physical, electronic,
or human controls to identify or admit personnel with properly or human controls to identify or admit personnel with properly
authorized access to a SCIF. authorized access to a SCIF.
Authentication Authentication
[RFC4949] describes authentication as the process of verifying [RFC4949] describes authentication as the process of verifying
(i.e., establishing the truth of) an attribute value claimed by or (i.e., establishing the truth of) an attribute value claimed by or
for a system entity or system resource. Authentication has two for a system entity or system resource. Authentication has two
skipping to change at page 4, line 26 skipping to change at page 4, line 26
data. data.
Data Integrity Data Integrity
[RFC4949] states data integrity includes: [RFC4949] states data integrity includes:
1. (I) The property that data has not been changed, destroyed, 1. (I) The property that data has not been changed, destroyed,
or lost in an unauthorized or accidental manner. [...] or lost in an unauthorized or accidental manner. [...]
2. (O) "The property that information has not been modified or 2. (O) "The property that information has not been modified or
destroyed in an unauthorized manner." [I7498-2] destroyed in an unauthorized manner."
Data Privacy Data Privacy
[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.
Identity Identity
[RFC4949] (I) The collective aspect of a set of attribute values [RFC4949] (I) The collective aspect of a set of attribute values
skipping to change at page 5, line 42 skipping to change at page 5, line 42
[RFC4949] describes a security audit trail as "A chronological [RFC4949] describes a security audit trail as "A chronological
record of system activities that is sufficient to enable the record of system activities that is sufficient to enable the
reconstruction and examination of the sequence environments and reconstruction and examination of the sequence environments and
activities surrounding or leading to an operation, procedure, or activities surrounding or leading to an operation, procedure, or
event in a security-relevant transaction from inception to final event in a security-relevant transaction from inception to final
results." results."
Requirements to support a security audit is not covered in this Requirements to support a security audit is not covered in this
document. document.
[I-D.ietf-i2rs-traceability] describes traceability for I2RS [RFC7922] describes traceability for I2RS interface and the I2RS
interface and the I2RS protocol. Traceability is not equivalent protocol. Traceability is not equivalent to a security audit
to a security audit trail. trail.
Trust Trust
[RFC4949] [RFC4949]
1. (I) /information system/ A feeling of certainty (sometimes 1. (I) /information system/ A feeling of certainty (sometimes
based on inconclusive evidence) either (a) that the system based on inconclusive evidence) either (a) that the system
will not fail or (b) that the system meets its specifications will not fail or (b) that the system meets its specifications
(i.e., the system does what it claims to do and does not (i.e., the system does what it claims to do and does not
perform unwanted functions). (See: trust level, trusted perform unwanted functions). (See: trust level, trusted
skipping to change at page 6, line 49 skipping to change at page 6, line 49
is a complete data message of one of the I2RS component protocols. is a complete data message of one of the I2RS component protocols.
The I2RS component protocols may require multiple IP-packets to The I2RS component protocols may require multiple IP-packets to
send one protocol message. send one protocol message.
I2RS multi-message atomicity I2RS multi-message atomicity
An I2RS operation (read, write, event, action) must be contained An I2RS operation (read, write, event, action) must be contained
within one I2RS message. Each I2RS operation must be atomic. within one I2RS message. Each I2RS operation must be atomic.
While it is possible to have an I2RS operation which is contained While it is possible to have an I2RS operation which is contained
in multiple I2RS (E.g. write in multiple messages), this is not in multiple I2RS (E.g. write in multiple messages), this is not
supported in order to simply the first version of I2RS. Multiple- supported in order to simplify the first version of I2RS.
message atomicity of I2RS operations would be used in a roll-back Multiple-message atomicity of I2RS operations would be used in a
of a grouping of commands (e.g. multiple writes). roll-back of a grouping of commands (e.g. multiple writes).
I2RS transaction I2RS transaction
is a unit of I2RS functionality. Some examples of I2RS is a unit of I2RS functionality. Some examples of I2RS
transactions are: transactions are:
* The I2RS client issues a read request to a I2RS agent, and the * The I2RS client issues a read request to a I2RS agent, and the
I2RS Agent responding to the read request I2RS Agent responding to the read request
* The I2RS client issues a write of ephemeral configuration * The I2RS client issues a write of ephemeral configuration
skipping to change at page 7, line 33 skipping to change at page 7, line 33
the I2RS Agent sets up to send the events. the I2RS Agent sets up to send the events.
* An I2RS agent sends events to an I2RS Client on an existing * An I2RS agent sends events to an I2RS Client on an existing
connection. connection.
An I2RS action may require multiple I2RS messages in order to An I2RS action may require multiple I2RS messages in order to
complete a transation. complete a transation.
I2RS secondary identifier I2RS secondary identifier
The I2RS architecture document [I-D.ietf-i2rs-architecture] The I2RS architecture document [RFC7921] defines a secondary
defines a secondary identity as the entity of some non-I2RS entity identity as the entity of some non-I2RS entity (e.g. application)
(e.g. application) which has requested a particular I2RS client which has requested a particular I2RS client perform an operation.
perform an operation. The I2RS secondary identifier represents The I2RS secondary identifier represents this identity so it may
this identity so it may be distinguished from all others. be distinguished from all others.
3. Security-Related Requirements 3. 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 a non-secure transport. transport, but some functions may operate on a non-secure transport.
The I2RS protocol MUST be able to provide atomicity of an I2RS The I2RS protocol MUST be able to provide atomicity of an I2RS
transaction, but it is not required to have multi-message atomicity transaction, but it is not required to have multi-message atomicity
and roll-back mechanism transactions. Multiple messages transactions and roll-back mechanism transactions. Multiple messages transactions
skipping to change at page 8, line 12 skipping to change at page 8, line 12
There are dependencies in some of the requirements below. For There are dependencies in some of the requirements below. For
confidentiality (section 3.3) and integrity (section 3.4) to be confidentiality (section 3.3) and integrity (section 3.4) to be
achieved, the client-agent must have mutual authentication (section achieved, the client-agent must have mutual authentication (section
3.1) and secure transport (section 3.2). I2RS allows the use of an 3.1) and secure transport (section 3.2). I2RS allows the use of an
insecure transport for portions of data models that clearly indicate insecure transport for portions of data models that clearly indicate
insecure transport. If insecure transport is used, then insecure transport. If insecure transport is used, then
confidentiality and integrity cannot be achieved. confidentiality and integrity cannot be achieved.
3.1. Mutual authentication of an I2RS client and an I2RS Agent 3.1. Mutual authentication of an I2RS client and an I2RS Agent
The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following The I2RS architecture [RFC7921] sets the following requirements:
requirements:
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.
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
skipping to change at page 10, line 51 skipping to change at page 10, line 51
Requirements SEC-REQ-14 and SEC-REQ-15 are SHOULD requirements only Requirements SEC-REQ-14 and SEC-REQ-15 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-16: 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 [RFC7922] and [RFC7923] SHOULD be
supported in communication channel that is non-secure to trace or
[I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in notify about potential security issues.
communication channel that is non-secure to trace or notify about
potential security issues.
3.5. Role-Based Data Model Security 3.5. Role-Based Data Model Security
The I2RS Architecture [I-D.ietf-i2rs-architecture] defines a role or The I2RS Architecture [RFC7921] defines a role or security role as
security role as specifying read, write, or notification access by a specifying read, write, or notification access by a I2RS client to
I2RS client to data within an agent's data model. data within an agent's data model.
SEC-REQ-17: 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-18: 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 [RFC7921] states. These transport message
transport message streams may start/stop without affecting the streams may start/stop without affecting the existence of the client/
existence of the client/agent data exchange. TCP supports a single agent data exchange. TCP supports a single stream of data. SCTP
stream of data. SCTP [RFC4960] provides security for multiple [RFC4960] provides security for multiple streams plus end-to-end
streams plus end-to-end transport of data. transport of data.
SEC-REQ-19: 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 multiple secure software using I2RS client functions may host 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
skipping to change at page 12, line 32 skipping to change at page 12, line 32
6. Security Considerations 6. Security Considerations
This is a document about security requirements for the I2RS protocol This is a document about security requirements for the I2RS protocol
and data modules. The whole document is security considerations. and data modules. The whole document is security considerations.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-15 (work in
progress), April 2016.
[I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-11 (work in progress), May 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <http://www.rfc-editor.org/info/rfc4107>. June 2005, <http://www.rfc-editor.org/info/rfc4107>.
[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem
Statement for the Interface to the Routing System",
RFC 7920, DOI 10.17487/RFC7920, June 2016,
<http://www.rfc-editor.org/info/rfc7920>.
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
<http://www.rfc-editor.org/info/rfc7921>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-i2rs-ephemeral-state] [I-D.ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", draft-ietf-i2rs-ephemeral-state-06 (work in Requirements", draft-ietf-i2rs-ephemeral-state-15 (work in
progress), May 2016. progress), July 2016.
[I-D.ietf-i2rs-pub-sub-requirements]
Voit, E., Clemm, A., and A. Prieto, "Requirements for
Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub-
requirements-09 (work in progress), May 2016.
[I-D.ietf-i2rs-security-environment-reqs] [I-D.ietf-i2rs-security-environment-reqs]
Migault, D., Halpern, J., and S. Hares, "I2RS Environment Migault, D., Halpern, J., and S. Hares, "I2RS Environment
Security Requirements", draft-ietf-i2rs-security- Security Requirements", draft-ietf-i2rs-security-
environment-reqs-01 (work in progress), April 2016. environment-reqs-01 (work in progress), April 2016.
[I-D.ietf-i2rs-traceability]
Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and
Information Model", draft-ietf-i2rs-traceability-11 (work
in progress), May 2016.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <http://www.rfc-editor.org/info/rfc4949>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>. <http://www.rfc-editor.org/info/rfc4960>.
[RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and
Information Model", RFC 7922, DOI 10.17487/RFC7922, June
2016, <http://www.rfc-editor.org/info/rfc7922>.
[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
for Subscription to YANG Datastores", RFC 7923,
DOI 10.17487/RFC7923, June 2016,
<http://www.rfc-editor.org/info/rfc7923>.
Authors' Addresses Authors' Addresses
Susan Hares Susan Hares
Huawei Huawei
7453 Hickory Hill 7453 Hickory Hill
Saline, MI 48176 Saline, MI 48176
USA USA
Email: shares@ndzh.com Email: shares@ndzh.com
Daniel Migault Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8400 boulevard Decarie
Montreal, QC HAP 2N2 Montreal, QC HAP 2N2
Canada Canada
Email: daniel.migault@ericsson.com Email: daniel.migault@ericsson.com
Joel Halpern Joel Halpern
Ericsson Ericsson
US US
Email: joel.halpern@ericsson.com Email: joel.halpern@ericsson.com
 End of changes. 23 change blocks. 
65 lines changed or deleted 58 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/