I2RS working group S. Hares
Internet-Draft Huawei
Intended status: Standards Track June 10, 2015
Expires: December 12, 2015
I2RS Security Related Requirements
draft-hares-i2rs-auth-trans-00
Abstract
This presents an security-related requirements for the I2RS protocol
for mutual authentication, transport protocols, data transfer and
transactions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hares Expires December 12, 2015 [Page 1]
Internet-Draft I2RS Security Requirements June 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. 10 I2RS General Requirements . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security-Related Requirements . . . . . . . . . . . . . . . . 6
3.1. Mutual authentication of I2RS client and I2RS Agent . . . 6
3.2. Transport Requirements Based on Mutual Authentication . . 7
3.2.1. NETCONF over SSH . . . . . . . . . . . . . . . . . . 7
3.2.2. NETCONF/RESTCONF over TLS . . . . . . . . . . . . . . 8
3.3. Data Confidentiality Requirements . . . . . . . . . . . . 8
3.4. Message Integrity Requirements . . . . . . . . . . . . . 8
3.5. Role-Based Data Model Security . . . . . . . . . . . . . 9
4. Data Transaction Requirements . . . . . . . . . . . . . . . . 9
5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The Interface to the Routing System (I2RS) provides read and write
access to the information and state within the routing process. The
I2RS client interacts with one or more I2RS agents to collect
information from network routing systems.
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
were initially described in the [I-D.ietf-i2rs-architecture]
document. These security requirements are also part of the list of
top ten requirements for the I2RS protocol indicated in the section
below.
[I-D.haas-i2rs-ephemeral-state-reqs] discusses of I2RS roles-based
write conflict resolution in the ephemeral data store using the I2RS
Client Identity, I2RS Secondary Identity and priority. The draft
[I-D.ietf-i2rs-traceability] describes the traceability framework and
its requirements for I2RS. The draft
[I-D.ietf-i2rs-pub-sub-requirements] describe the requirements for
I2RS to be able to publish information or have a remote client
subscribe to an information data stream.
Hares Expires December 12, 2015 [Page 2]
Internet-Draft I2RS Security Requirements June 2015
1.1. 10 I2RS General Requirements
o 1. The I2RS protocol SHOULD support highly reliable notifications
(but not perfectly reliable notifications) from an I2RS agent to
an I2RS client.
o 2. The I2RS protocol SHOULD support a high bandwidth,
asynchronous interface, with real-time guarantees on getting data
from an I2RS agent by an I2RS client.
o 3. The I2RS protocol will operate on data models which may be
protocol independent or protocol dependent.
o 4. I2RS Agent needs to record the client identity when a node is
created or modified. The I2RS Agent needs to be able to read the
client identity of a node and use the client identity's associated
priority to resolve conflicts. The secondary identity is useful
for traceability and may also be recorded.
o 5. Client identity will have only one priority for the client
identity. A collision on writes is considered an error, but
priority is utilized to compare requests from two different
clients in order to modify an existing node entry. Only an entry
from a client which is higher priority can modify an existing
entry (First entry wins). Priority only has meaning at the time
of use.
o 6. The Agent identity and the Client identity should be passed
outside of the I2RS protocol in a authentication and authorization
protocol (AAA). Client priority may be passed in the AAA
protocol. The values of identities are originally set by
operators, and not standardized.
o 7.An I2RS Client and I2RS Agent mutually authenticate each other
based on pre-established authenticated identities.
o 8. Secondary identity data is read-only meta-data that is
recorded by the I2RS agent associated with a data model's node is
written, updated or deleted. Just like the primary identity, the
secondary identity is only recorded when the data node is written
or updated or deleted.
o 9.I2RS agent can have a lower priority I2RS client attempting to
modify a higher priority client's entry in a data model. The
filtering out of lower priority clients attempting to write or
modify a higher priority client's entry in a data model SHOULD be
effectively handled and not put an undue strain on the I2RS agent.
Note: Jeff's suggests that priority is kept at the NACM at the
Hares Expires December 12, 2015 [Page 3]
Internet-Draft I2RS Security Requirements June 2015
client level (rather than the path level or the group level) will
allow these lower priority clients to be filtered out using an
extended NACM approach. This is only a suggestion of a method to
provide the requirement
o 10. The I2RS protocol MUST support the use of a secure transport.
However, certain functions such as notifications MAY use a non-
secure transport. Each model or service (notification, logging)
must define within the model or service the valid uses of a non-
secure transport.
2. Definitions
This document utilizes the definitions found in the following drafts:
[RFC4949], and [I-D.ietf-i2rs-architecture]
Specifically, this document utilizes the following definitions:
Authentication
[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.
Data Confidentiality
[RFC4949] describes data confidentiality as having two properties:
a) data is not disclosed to system entities unless they have been
authorized to know, and b) data is not disclosed to unauthorized
individuals, entities or processes. 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.
Data confidentiality service
[RFC4949] also describes data confidentiality service as a
security service that protects data against unauthorized
disclosure. Please note that an operator can designate all people
are authorized to view a piece of data which would mean a data
confidentiality service would be essentially a null function.
Data Privacy
[RFC4949] describes data privacy as a synonym for data
confidentiality. This I2RS document will utilize data privacy as
a synonym for data confidentiality.
Hares Expires December 12, 2015 [Page 4]
Internet-Draft I2RS Security Requirements June 2015
Mutual Authentication
[RFC4949] implies that mutual authentication exists between two
interacting system entities. Mutual authentication in I2RS
implies that both sides move from a state of mutual suspicion to
mutually authenticated communication afte each system has been
identified and validated by its peer system
Mutual Suspicion
[RFC4949] defines mutual suspicion as a state that exists between
two interacting system entities in which neither entity can trust
the other to function correctly with regard to some security
requirement.
Role
[RFC4949] describes role as a job function or employment position
to which people or other system entities may be assigned in a
system. In the I2RS interface, the I2RS agent roles relate to the
roles that the I2RS client is utilizing. In the I2RS interface,
the I2RS client negotiation is over the client's ability to access
resources made available through the agent's particular role.
Role-based Access control
[RFC4949] describes role-based access control as an identity-based
access control wherein the system entities that are identified and
controlled are functional positions in an organization or process.
Within [RFC4949] five relationships are discussed: 1)
administrators to assign identities to roles, 2) administrators to
assign permissions to roles, 3) administrators to assign roles to
roles, 4) users to select identities in sessions, and 5) users to
select roles in sessions.
Security audit trail
[RFC4949] (page 254) 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. Requirements to support a
security audit is not covered in this document. The draft
[I-D.ietf-i2rs-traceability] describes traceability for I2RS
interface and protocol.
I2RS integrity
Hares Expires December 12, 2015 [Page 5]
Internet-Draft I2RS Security Requirements June 2015
The data transfer as it is transmitted between client and agent
cannot be modified by unauthorized parties without detection.
3. Security-Related Requirements
The security for the I2RS protocol requires mutually authenticated
I2RS client and I2RS agent MUST be able to exchange data over a
secure transport, and MUST use role-based security to store data in
I2RS data models in ephemeral state, and MUST provide atomicity of a
transaction. This section describes the requirements for the mutual
authentication of the I2RS agent and client, and the secure
transport. The issues relating to role-based security to store data
in I2RS data models in ephemeral state is covered in
[I-D.haas-i2rs-ephemeral-state-reqs].
3.1. Mutual authentication of I2RS client and I2RS Agent
The I2RS architecture [I-D.ietf-i2rs-architecture]document states:
"Mutual authentication between the I2RS Client and I2RS Agent is
required. An I2RS Client must be able to trust that the I2RS
Agent is attached to the relevant Routing Element so that write/
modify operations are correctly applied and so that information
received from the I2RS Agent can be trusted by the I2RS Client."
This architecture set the following requirements:
o All I2RS clients and I2RS agents MUST have at least one unique
identifier that uniquely identifies each party.
o The I2RS protocol MUST utilize these identifiers for mutual
identification of the I2RS client and I2RS agent.
o An I2RS agent, upon receiving an I2RS message from a client, must
confirm that the client has a valid identity.
o The client, upon receiving an I2RS message from an agent, must
confirm the I2RS identity.
o Identity distribution and the loading of these identities into
I2RS agent and I2RS Client occur outside the I2RS protocol.
o The I2RS protocol SHOULD assume some mechanism (IETF or private)
in order to distribute or load identities and that the I2RS
client/agent will load the identities prior to the I2RS protocol
establishing a connection between I2RS client and I2RS agent.
o Each Identity will be linked to one priority
Hares Expires December 12, 2015 [Page 6]
Internet-Draft I2RS Security Requirements June 2015
o Each Identity will be linked to one secondary identity for the
period of a connection.
3.2. Transport Requirements Based on Mutual Authentication
I2RS data security MUST be able to support transfer of the data
between the I2RS client to I2RS agent in a manner that is
confidential, has message integrity, and supports end-to-end
integrity (in the case of stacked clients).
The I2RS data security mechanisms used for protecting the I2RS
packets needs to be associated with proper key management solutions.
A key management solution needs to guarantee that only the entities
having sufficient privileges can get the keys to encrypt/decrypt the
sensitive data. In addition, the key management mechanisms need to
be able to update the keys before they have lost sufficient security
strengths, without breaking the connection between the agents and
clients.
The rules around what role is permitted to access and manipulate what
information, combined with encryption to protect the data in transit
is intended SHOULD ensure that data of any level of sensitivity is
reasonably protected from being observed by those without permission
to view it. In that case 'those' can refer to either other roles,
sub-agents, or to attackers and assorted MITM (man-in-the-
middle)monkeys.
The I2RS protocol MUST support multiple transport sessions providing
protocol and data communication between the I2RS Agent and the I2RS
client.
3.2.1. NETCONF over SSH
The NETCONF service over SSH is believed to provide the necessary
mutual authentication services required by I2RS. Per [RFC6242]: "The
identity of the SSH server MUST be verified and authenticated by the
SSH client according to local policy before password-based
authentication data or any configuration or state data is sent to or
received from the SSH server. The identity of the SSH client MUST
also be verified and authenticated by the SSH server according to
local policy to ensure that the incoming SSH client request is
legitimate before any configuration or state data is sent to or
received from the SSH client. Neither side should establish a
NETCONF over SSH connection with an unknown, unexpected, or incorrect
identity on the opposite side.
Hares Expires December 12, 2015 [Page 7]
Internet-Draft I2RS Security Requirements June 2015
3.2.2. NETCONF/RESTCONF over TLS
Agent validation of the I2RS client is mandated over TLS in an I2RS
context. The client shall also validate the Agent using its server
certificate.
3.3. Data Confidentiality Requirements
In a critical infrastructure, certain data within routing elements is
sensitive and read/write operations on such data must 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.
It is normal to protect the confidentiality of the sensitive data
during transportation by encrypting them. Encryption obscures the
data transported on the wire and protects them against eavesdropping
attacks. Because the encryption itself cannot guarantee the
integrity or fresh of data being transported, in practice,
confidentiality protection is normally provided with integrity
protection.
3.4. Message Integrity Requirements
An integrity protection mechanism for I2RS should be able to ensure
1) the data being protected are not modified without detection during
its transportation and 2) the data is actually from where it is
expected to come from 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 are not modified or replayed without detection.
As a part of integrity protection, the replay protection approaches
provided for I2RS must consider both online and offline attackers,
and have sufficient capability to deal with intra connection and
inter-connection attacks. For instance, when using symmetric keys,
sequence numbers which increase monotonically could be useful to help
in distinguishing the replayed messages, under the assistance of
signatures or MACs (dependent on what types of keys are applied). In
addition, in the cases where only offline attacker is considered,
random nonce could be effective.
Hares Expires December 12, 2015 [Page 8]
Internet-Draft I2RS Security Requirements June 2015
3.5. Role-Based Data Model Security
The context of the I2RS client-agent communication may utilize a role
which may/may not require message confidentiality, message integrity
protection, or replay attack protection. However, the I2RS Protocol
MUST be able to support message confidentiality, message integrity
protection, and replay attack protection.
Role security for an agent involves pairing the identity to the role.
The data store can read information either by write or an event
stream.
Role security MUST work when multiple transport connections are being
used between the I2RS client and I2RS agent as the I2RS architecture
[I-D.ietf-i2rs-architecture] 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 [RFC4960]
provides security for multiple streams plus end-to-end transport of
data.
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. An application software
using I2RS client functions can host several multiple secure
identities, but each connection will use only one identity with one
priority.. Therefore, the security of each connection is unique.
4. Data Transaction Requirements
Each transaction should be treated as atomic and providing full
functionality. If the configuration change is not functionally
complete, then the transaction should fail and be rolled back
(rollback 0). Example, I2RS agents wants to configure BGP:
routing-options {
autonomous-system autonomous-system;
}
protocols {
bgp {
group group-name {
peer-as autonomous-system;
type type;
neighbor address;
}
}
}
Hares Expires December 12, 2015 [Page 9]
Internet-Draft I2RS Security Requirements June 2015
If a statement like neighbor address is missing or is mis-formatted,
like 300.127.5.23, configuration is not functional, transaction
should fail and rollback 0 should be performed by the I2RS agent on
the ephemeral config store. If the neighbor address is in the
transaction, but the address is not reachable or similar, transaction
is accepted, but notification will be sent that BGP peering cannot be
established.
5. Acknowledgement
The author 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 I2RS security
requirement discussion, and this document.
6. IANA Considerations
This draft includes no request to IANA.
7. Security Considerations
This is a document about security architecture beyond the
consideration for I2RS. Additional security definitions will be
added in this section.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.haas-i2rs-ephemeral-state-reqs]
Haas, J., "I2RS Ephemeral State Requirements", draft-haas-
i2rs-ephemeral-state-reqs-00 (work in progress), May 2015.
[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-09 (work in
progress), March 2015.
[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-06 (work in progress), January 2015.
Hares Expires December 12, 2015 [Page 10]
Internet-Draft I2RS Security Requirements June 2015
[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-02 (work in progress), March 2015.
[I-D.ietf-i2rs-rib-info-model]
Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
Information Base Info Model", draft-ietf-i2rs-rib-info-
model-06 (work in progress), March 2015.
[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-03 (work
in progress), May 2015.
[RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK)
Ciphersuites with NULL Encryption for Transport Layer
Security (TLS)", RFC 4785, January 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007.
Author's Address
Susan Hares
Huawei
7453 Hickory Hill
Saline, MI 48176
USA
Email: shares@ndzh.com
Hares Expires December 12, 2015 [Page 11]