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/