One document matched: draft-ietf-i2rs-protocol-security-requirements-05.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4107.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY I-D.ietf-i2rs-problem SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-pub-sub-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-pub-sub-requirements.xml">
<!ENTITY I-D.ietf-i2rs-traceability SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-traceability.xml">
<!ENTITY I-D.ietf-i2rs-ephemeral-state SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-ephemeral-state.xml">
<!ENTITY I-D.ietf-i2rs-security-environment-reqs SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-security-environment-reqs.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="info" docName="draft-ietf-i2rs-protocol-security-requirements-05" ipr="trust200902">
<front>
<title abbrev="I2RS Security Requirements">I2RS Security Related Requirements</title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Daniel Migault" initials="D" surname="Migault">
<organization>Ericsson</organization>
<address>
<postal>
<street>8400 boulevard Decarie</street>
<city>Montreal</city>
<region>QC</region>
<code>HAP 2N2</code>
<country>Canada</country>
</postal>
<email>daniel.migault@ericsson.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Joel Halpern" initials="J" surname="Halpern">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>US</country>
</postal>
<email>joel.halpern@ericsson.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2016" />
<area>Routing Area</area>
<workgroup>I2RS working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t> This presents security-related requirements for the I2RS
protocol for mutual authentication, transport protocols,
data transfer and transactions.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Interface to the Routing System (I2RS)
provides read and write access to information and state within the
routing process. An I2RS client interacts with one or more I2RS agents to collect information
from network routing systems. </t>
<t> This document describes the requirements for the
I2RS protocol in the security-related areas of mutual authentication of the
I2RS client and agent, the transport protocol carrying the I2RS
protocol messages, and the atomicity of the transactions.
These requirements align with the description of the I2RS architecture found in
<xref target="I-D.ietf-i2rs-architecture"></xref> document which solves the problem
described in <xref target="I-D.ietf-i2rs-problem-statement"></xref>.</t>
<t>
<xref target="I-D.ietf-i2rs-ephemeral-state"></xref> discusses I2RS role-based access control
that provides write conflict resolution in the ephemeral data store using the I2RS Client Identity,
I2RS Secondary Identity and priority. The draft <xref target="I-D.ietf-i2rs-traceability"></xref>
describes the traceability framework and its requirements for I2RS.
The draft <xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref>
describes the requirements for I2RS to be able to publish information or
have a remote client subscribe to an information data stream.
</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Definitions" >
<section title="Security Definitions">
<t>This document utilizes the definitions found in the
following documents: <xref target="RFC4949"></xref> and <xref target="I-D.ietf-i2rs-architecture"></xref>
</t>
<t> Specifically, this document utilizes the following definitions:
<list style="hanging">
<t hangText="access control"><vspace blankLines="1"/> <xref target="RFC4949" /> defines
access control as the following:
<list>
<t>
1. (I) Protection of system resources against unauthorized access.
</t>
<t>
2. (I) A process by which use of system resources is regulated
according to a security policy and is permitted only by authorized
entities (users, programs, processes, or other systems) according
to that policy. (See: access, access control service, computer
security, discretionary access control, mandatory access control,
role-based access control.)
</t>
<t>
3. (I) /formal model/ Limitations on interactions between subjects
and objects in an information system.
</t>
<t>
4. (O) "The prevention of unauthorized use of a resource,
including the prevention of use of a resource in an unauthorized
manner." [I7498-2]
</t>
<t>
5. (O) /U.S. Government/ A system using physical, electronic, or
human controls to identify or admit personnel with properly
authorized access to a SCIF.
</t>
</list> </t>
<t hangText="Authentication"><vspace blankLines="1"/> <xref target="RFC4949" />
describes authentication as the process of verifying (i.e., establishing the truth of)
an attribute value claimed by or for a system entity or system
resource. Authentication has two steps: identify and verify. </t>
<t hangText="Data Confidentiality"><vspace blankLines="1"/> <xref target="RFC4949" />
describes data confidentiality as having two properties:
<list style="hanging">
<t>a) Data is not disclosed to system entities unless they have been
authorized to know the data, and
</t>
<t>b) Data is not disclosed to unauthorized individuals, entities or
processes.
</t>
</list>
The key point is that
confidentiality implies that the originator has the ability to authorize where the
information goes. Confidentiality is important for both read and write scope of the
data.</t>
<t hangText="Data Integrity"><vspace blankLines="1"/> <xref target="RFC4949" />
states data integrity includes:
<list>
<t>
1. (I) The property that data has not been changed, destroyed, or
lost in an unauthorized or accidental manner. [...]
</t>
<t>
2. (O) "The property that information has not been modified or
destroyed in an unauthorized manner." [I7498-2]
</t>
</list>
</t>
<t hangText="Data Privacy"><vspace blankLines="1"/> <xref target="RFC4949" /> describes
data privacy as a synonym for data confidentiality. This I2RS document will utilize
data privacy as a synonym for data confidentiality. </t>
<t hangText="Identity"><vspace blankLines="1"/><xref target="RFC4949" />
(I) The collective aspect of a set of attribute values (i.e., a
set of characteristics) by which a system user or other system
entity is recognizable or known. (See: authenticate, registration.
Compare: identifier.)
</t>
<t hangText="Identifier"><vspace blankLines="1"/><xref target="RFC4949" />
(I) A data object -- often, a printable, non-blank character
string -- that definitively represents a specific identity of a
system entity, distinguishing that identity from all others.
(Compare: identity.)
</t>
<t hangText="Mutual Authentication"><vspace blankLines="1"/><xref target="RFC4949" />
implies that mutual authentication exists between two interacting system
entities. </t>
<t>Mutual authentication in I2RS implies that both sides move from
a state of mutual suspicion to to mutual authentication to
trusted mutual communication after each system has been identified
and validated by its peer system.</t>
<t hangText="role"><vspace blankLines="1"/> <xref target="RFC4949" /> describes role as:
<list>
<t>
1. (I) A job function or employment position to which people or
other system entities may be assigned in a system. [...]
</t>
<t>
2. (O) /Common Criteria/ A pre-defined set of rules establishing
the allowed interactions between a user and the TOE.
</t>
</list>
The I2RS uses the common criteria definition.
</t>
<t hangText="role-based access control"><vspace blankLines="1"/> <xref target="RFC4949" /> describes role-based
access control as: "A form of identity-based access control wherein the system
entities that are identified and controlled are functional
positions in an organization or process."
</t>
<t hangText="security audit trail"><vspace blankLines="1"/><xref target="RFC4949" /> describes
a security audit trail as "A chronological record of system activities that is sufficient
to enable the reconstruction and examination of the sequence
environments and activities surrounding or leading to an
operation, procedure, or event in a security-relevant transaction
from inception to final results."
</t>
<t>Requirements to support a security audit is not covered in this
document.</t>
<t><xref target="I-D.ietf-i2rs-traceability"></xref> describes traceability for I2RS interface and
the I2RS protocol. Traceability is not equivalent to a security audit trail. </t>
<t hangText="Trust"><vspace blankLines="1"/><xref target="RFC4949" />
<list style="numbers">
<t>(I) /information system/ A feeling of certainty (sometimes
based on inconclusive evidence) either (a) that the system will
not fail or (b) that the system meets its specifications (i.e.,
the system does what it claims to do and does not perform unwanted
functions). (See: trust level, trusted system, trustworthy system.
Compare: assurance.)
</t>
<t>. (I) /PKI/ A relationship between a certificate user and a CA in
which the user acts according to the assumption that the CA
creates only valid digital certificates. (Also referred as "trusted"
in <xref target="RFC4949"></xref>.)
</t>
</list>
</t>
</list>
</t>
</section>
<section title="I2RS Specific Definitions">
<t>
<list style="hanging">
<t hangText="I2RS protocol data integrity"><vspace blankLines="1" /> The transfer of data via the
I2RS protocol has the property of data integrity described in <xref target="RFC4949"/>.
</t>
<t hangText="I2RS component protocols"><vspace blankLines="1" /> Protocols which are combined to create the I2RS protocol.
</t>
<t hangText="I2RS Higher-level protocol"><vspace blankLines="1" /> The I2RS protocol
exists as a higher-level protocol which may combine other protocols (NETCONF, RESTCONF, IPFIX and others) within a
specific I2RS client-agent relationship with a specific trust for ephemeral configurations,
event, tracing, actions, and data flow interactions. The protocols included in the I2RS protocol
protocol are defined as I2RS component protocols. (Note: Version 1 of the I2RS protocol
will combine only NETCONF and RESTCONF. Experiments with other protocols such as IPFIX
have shown these are useful to combine with NETCONF and RESTCONF features.)
</t>
<t hangText="I2RS message"><vspace blankLines="1" />is a complete data message of
one of the I2RS component protocols. The I2RS component protocols may require
multiple IP-packets to send one protocol message.
</t>
<t hangText="I2RS multi-message atomicity"><vspace blankLines="1" />
An I2RS operation (read, write, event, action) must be contained within one I2RS message.
Each I2RS operation must be atomic. While it is possible to have an I2RS
operation which is contained in multiple I2RS (E.g. write in multiple messages),
this is not supported in order to simply the first version of I2RS.
Multiple-message atomicity of I2RS operations would be used in
a roll-back of a grouping of commands (e.g. multiple writes).
</t>
<t hangText="I2RS transaction"><vspace blankLines="1" /> is a unit of
I2RS functionality. Some examples of I2RS transactions are:
<list style="symbols">
<t>The I2RS client issues a read request to a I2RS agent, and the
I2RS Agent responding to the read request </t>
<t>The I2RS client issues a write of ephemeral configuration values into an I2RS agent's
data model, followed by the I2RS agent response to the write.
</t>
<t>An I2RS client may issue an action request, the I2RS agent responds to the
action-request, and then responds when action is complete.
Actions can be single step processes or multiple step process.
</t>
<t>An I2RS client requests to receive an event notification, and
the I2RS Agent sets up to send the events.</t>
<t>An I2RS agent sends events to an I2RS Client on an existing
connection.</t>
</list>
An I2RS action may require multiple I2RS messages in order to complete
a transation.
</t>
<t hangText="I2RS secondary identifier"><vspace blankLines="1" />
The I2RS architecture document <xref target="I-D.ietf-i2rs-architecture"></xref>
defines a secondary identity as the entity of some non-I2RS entity (e.g. application)
which has requested a particular I2RS client perform an operation. The I2RS secondary
identifier represents this identity so it may be distinguished from all others.
</t>
</list>
</t>
</section>
</section>
<section title="Security-Related Requirements" >
<t> The security for the I2RS protocol requires mutually authenticated I2RS clients and I2RS agents.
The I2RS client and I2RS agent using the I2RS protocol MUST be able to exchange
data over a secure transport, but some functions may operate on a non-secure
transport. The I2RS protocol MUST be able to provide atomicity of an I2RS transaction, but it is
not required to have multi-message atomicity and roll-back mechanism transactions. Multiple messages
transactions may be impacted by the interdependency of data. This section discusses the
details of these security requirements.
</t>
<t>There are dependencies in some of the requirements below. For
confidentiality (section 3.3) and integrity (section 3.4) to be achieved, the
client-agent must have mutual authentication (section 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. If insecure transport is used, then confidentiality and
integrity cannot be achieved.
</t>
<section title="Mutual authentication of an I2RS client and an I2RS Agent ">
<t>The I2RS architecture <xref target="I-D.ietf-i2rs-architecture"></xref>
sets the following requirements:
<list style="symbols">
<t>SEC-REQ-01: All I2RS clients and I2RS agents MUST have an identity, and at least one unique
identifier that uniquely identifies each party in the I2RS protocol context. </t>
<t>SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for mutual identification of
the I2RS client and I2RS agent. </t>
<!-- XXX JMH - "message" below is ambiguous within the context of our document set. Suggest clarifying -->
<t>SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a
I2RS client, MUST confirm that the I2RS client has a valid identifier.</t>
<t>SEC-REQ-04: The I2RS client, upon receiving an I2RS message from an
I2RS agent, MUST confirm the I2RS agent has a valid identifier.</t>
<t>SEC-REQ-05: Identifier distribution and the loading of these identifiers into I2RS agent
and I2RS Client SHOULD occur outside the I2RS protocol. </t>
<t>SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF or private) will
distribute or load identifiers so that the I2RS client/agent has these
identifiers prior to the I2RS protocol establishing a connection
between I2RS client and I2RS agent. </t>
<t> SEC-REQ-07: Each Identifier MUST have just one priority.</t>
<!-- XXX JMH - the conditional but clause below could use restating. -->
<t> SEC-REQ-08: Each Identifier is associated with one secondary identifier during a
particular I2RS transaction (e.g. read/write sequence), but the secondary
identifier may vary during the time a connection between the I2RS client and
I2RS agent is active. Since a single I2RS client may be use by multiple
applications, the secondary identifier may vary as the I2RS client is
utilize by different application each of whom have a unique secondary identity
and identifier. </t>
</list>
</t>
</section>
<section title="Transport Requirements Based on Mutual Authentication" >
<t>SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
secure transport and optionally MAY be able to transfer data over a
non-secure transport. A secure transport MUST provide data
confidentiality, data integrity, and replay prevention.
</t>
<t>
The default I2RS transport is a secure transport.
</t>
<t>
A non-secure transport can be can be used for publishing telemetry data
or other operational state that was specifically indicated to
non-confidential in the data model in the Yang syntax.
</t>
<t>The configuration of ephemeral data in the I2RS Agent by the
I2RS client SHOULD be done over a secure transport. It is anticipated
that the passing of most I2RS ephemeral state operational
status SHOULD be done over a secure transport.
As <xref target="I-D.ietf-i2rs-ephemeral-state"></xref> notes
data model MUST indicate whether the transport
exchanging the data between I2RS client and I2RS agent is
secure or insecure. The default mode of transport is
secure so data models SHOULD clearly annotate what data nodes can
be passed over an insecure connection.
</t>
<t>
SEC-REQ-10: A secure transport MUST be associated with a key management
solution that can guarantee that only the entities having sufficient privileges
can get the keys to encrypt/decrypt the sensitive data.
Per <xref target="RFC4107">BCP107</xref> this key management system SHOULD be automatic,
but MAY be manual in the following scenarios:
<list>
<t>a) The environment has limited bandwidth or high round-trip times.</t>
<t>b) The information being protected has low value.</t>
<t>c) The total volume of traffic over the entire lifetime of the long-term session key will be very low.</t>
<t>d) The scale of the deployment is limited.</t>
</list>
</t>
<t>
Most I2RS environments (Clients and Agents) will not have the environment
described by <xref target="RFC4107">BCP107</xref> but a few I2RS use cases
required limited non-secure light-weight telemetry messages
that have these requirements. An I2RS data model must indicate which portions can be
served by manual key management.
</t>
<t> SEC-REQ-11: The I2RS protocol MUST be able to support multiple secure transport
sessions providing protocol and data communication between an I2RS Agent
and an I2RS client. However, a single I2RS Agent to I2RS client connection MAY
elect to use a single secure transport session or a single
non-secure transport session. </t>
<t>SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement
mechanisms that mitigate DoS attacks.</t>
</section>
<section title="Data Confidentiality Requirements">
<t>SEC-REQ-13: In a critical infrastructure, certain data within routing elements is
sensitive and read/write operations on such data SHOULD be controlled in order to protect
its confidentiality. For example, most carriers do not want a router's
configuration and data flow statistics known by hackers or their competitors.
While carriers may share peering information, most carriers do not share
configuration and traffic statistics. To achieve this, access control to sensitive
data needs to be provided, and the confidentiality protection on
such data during transportation needs to be enforced.
</t>
</section>
<section title="Data Integrity Requirements">
<t> SEC-REQ-14: An integrity protection mechanism for I2RS SHOULD be able to ensure the following:
<list>
<t>1) the data being protected is not modified without detection during
its transportation,
</t>
<t>2) the data is actually from where it is expected to come from, and
</t>
<t>3) the data is not repeated from some earlier interaction of the protocol.
(That is, when both confidentiality and integrity of data is properly protected, it
is possible to ensure that encrypted data is not modified
or replayed without detection.)
</t>
</list>
</t>
<t>SEC-REQ-15: The integrity that the message data is not repeated
means that I2RS client to I2RS agent transport SHOULD protect against replay attack </t>
<t>Requirements SEC-REQ-14 and SEC-REQ-16 are SHOULD requirements only because it is recognized
that some I2RS Client to I2RS agent communication occurs over a non-secure channel.
The I2RS client to I2RS agent over a secure channel would implement these features.
In order to provide some traceability or notification for the non-secure protocol,
SEC-REQ-16 suggests traceability and notification are important to include for
any non-secure protocol.</t>
<t>SEC-REQ-16: The I2RS message traceability and notification requirements
requirements found in <xref target="I-D.ietf-i2rs-traceability"></xref> and
<xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref> SHOULD be supported
in communication channel that is non-secure to trace or notify about potential
security issues.</t>
</section>
<section title="Role-Based Data Model Security">
<t>The <xref target="I-D.ietf-i2rs-architecture">I2RS Architecture</xref> defines a
role or security role as specifying read, write, or notification access by a I2RS client to
data within an agent's data model.
</t>
<t> SEC-REQ-17: The rules around what role is permitted to access and manipulate what
information plus a secure transport (which protects the data in transit)
SHOULD ensure that data of any level of sensitivity is
reasonably protected from being observed by those without permission
to view it, so that privacy requirements are met.
</t>
<t> SEC-REQ-18: Role security MUST work when multiple transport connections are being used
between the I2RS client and I2RS agent as the <xref target="I-D.ietf-i2rs-architecture">I2RS architecture</xref> states.
These transport message streams may start/stop without affecting the existence of the client/agent
data exchange. TCP supports a single stream of data. SCTP <xref target="RFC4960" /> provides
security for multiple streams plus end-to-end transport of data.
</t>
<t> SEC-REQ-19: I2RS clients MAY be used by multiple applications to configure routing
via I2RS agents, receive status reports, turn on the I2RS audit stream, or turn
on I2RS traceability. Application software using I2RS client functions
may host multiple secure identities, but each connection will use
only one identifier with one priority. Therefore, the security of each
I2RS Client to I2RS Agent connection is unique.
</t>
<t> Please note the security of the application to
I2RS client connection is outside of the I2RS protocol or I2RS interface.
</t>
<t>Sec-REQ-20: If an I2RS agents or an I2RS client is tightly
correlated with a person, then the I2RS protocol and data models
should provide additional security that protects the person's privacy.
An example of an I2RS agent correlated with a person is a I2RS agent
running on someone's phone to control tethering, and an example of
a I2RS client might be the client tracking such tethering.
This protection MAY require a variety of forms including:
"operator-applied knobs", roles that restrict personal access,
data-models with specific "privacy roles", and access filters.
</t>
</section>
<section title="Security of the environment">
<t>The security for the implementation of a protocol also considers the
protocol environment. The environmental security requirements are found in:
<xref target="I-D.ietf-i2rs-security-environment-reqs"></xref>.
</t>
</section>
</section>
<section anchor="Acks" title="Acknowledgement">
<t>The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric Yu,
Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia Atlas, and Jeff Haas for their
contributions to the I2RS security requirements discussion and this document.
The authors would like to thank Bob Moskowitz for his review of the requirements.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft includes no request to IANA.</t>
</section>
<section title="Security Considerations">
<t>This is a document about security requirements for the I2RS protocol and
data modules. The whole document is security considerations. </t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4107;
&I-D.ietf-i2rs-problem;
&I-D.ietf-i2rs-architecture;
</references>
<references title="Informative References">
&RFC4949;
&RFC4960;
&I-D.ietf-i2rs-ephemeral-state;
&I-D.ietf-i2rs-traceability;
&I-D.ietf-i2rs-pub-sub-requirements;
&I-D.ietf-i2rs-security-environment-reqs;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:21:39 |