--- 1/draft-ietf-i2rs-security-environment-reqs-05.txt 2017-09-27 05:15:10.543344651 -0700 +++ 2/draft-ietf-i2rs-security-environment-reqs-06.txt 2017-09-27 05:15:10.599345993 -0700 @@ -1,20 +1,20 @@ I2RS WG D. Migault Internet-Draft J. Halpern Intended status: Informational Ericsson -Expires: September 29, 2017 S. Hares +Expires: March 31, 2018 S. Hares Huawei - March 28, 2017 + September 27, 2017 I2RS Environment Security Requirements - draft-ietf-i2rs-security-environment-reqs-05 + draft-ietf-i2rs-security-environment-reqs-06 Abstract This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of the protocol used for I2RS. The security environment requirements are the good security practices to be used during implementation and deployment of the code related to the new interface to routing system (I2RS) so that I2RS implementations can be securely deployed and operated. @@ -24,37 +24,37 @@ ietf-i2rs-protocol-security-requirements). 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/. + Drafts is at https://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 September 29, 2017. + This Internet-Draft will expire on March 31, 2018. Copyright Notice Copyright (c) 2017 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 + (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 @@ -89,29 +89,29 @@ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of the protocol used for I2RS. The I2RS protocol security requirements - [I-D.ietf-i2rs-protocol-security-requirements] define the security - for the communication between I2RS client and agent. The security - environment requirements are good security practices to be used - during implementation and deployment of the I2RS protocol so that - I2RS protocol implementations can be securely deployed and operated. - These environment security requirements address the security - considerations described in the I2RS Architecture [RFC7921] required - to provide a stable and secure environment in which the dynamic - programmatic interface to the routing system (I2RS) should operates. + [RFC8241] define the security for the communication between I2RS + client and agent. The security environment requirements are good + security practices to be used during implementation and deployment of + the I2RS protocol so that I2RS protocol implementations can be + securely deployed and operated. These environment security + requirements address the security considerations described in the + I2RS Architecture [RFC7921] required to provide a stable and secure + environment in which the dynamic programmatic interface to the + routing system (I2RS) should operates. Even though the I2RS protocol is mostly concerned with the interface between the I2RS client and the I2RS agent, the environmental security requirements must consider the entire I2RS architecture and specify where security functions may be hosted and what criteria should be met in order to address any new attack vectors exposed by deploying this architecture. Environment security for I2RS has to be considered for the complete I2RS architecture and not only on the protocol interface. @@ -136,22 +136,22 @@ another and without affecting the I2RS components. Applications may be independent, with different scopes, owned by different tenants. In addition, the applications may modify the routing system in an automatic way. Motivations are described before the requirements are given. The reader is expected to be familiar with the I2RS problem statement [RFC7920], I2RS architecture, [RFC7921], traceability requirements [RFC7922], I2RS Pub/Sub requirements [RFC7923], I2RS ephemeral state - requirements [I-D.ietf-i2rs-ephemeral-state], I2RS protocol security - requirements [I-D.ietf-i2rs-protocol-security-requirements]. + requirements [RFC8242], I2RS protocol security requirements + [RFC8241]. 2. Terminology and Acronyms - Environment Security Requirements : Security requirements specifying how the environment a protocol operates in needs to be secured. These requirements do not specify the protocol security requirements. - I2RS plane: The environment the I2RS process is running on. It includes the applications, the I2RS client, and the I2RS agent. @@ -372,24 +372,23 @@ SEC-ENV-REQ 1: Application-to-routing system resources communications should use an isolated communication channel. Various levels of isolation can be considered. The highest level of isolation may be provided by using a physically isolated network. Alternatives may also consider logical isolation (e.g. using vLAN). In a virtual environment that shares a common infrastructure, encryption may also be used as a way to enforce isolation. Encryption can be added by using a secure transport required by - the I2RS protocol security - [I-D.ietf-i2rs-protocol-security-requirements], and - sending the non-confidential I2RS data (designed for - a non-secure transport) over a secure transport. + the I2RS protocol security [RFC8241], and sending the + non-confidential I2RS data (designed for a non-secure + transport) over a secure transport. SEC-ENV-REQ 2: The interface used by the routing element to receive I2RS transactions via the I2RS protocol (e.g. the IP address) SHOULD be a dedicated physical or logical interface. As previously mentioned, a dedicated physical interface may contribute to a higher isolation. Isolation may also be achieved by using a dedicated IP address or a dedicated port. SEC-ENV-REQ 3: An I2RS agent SHOULD have specific permissions for @@ -481,26 +480,25 @@ identity and roles. The I2RS deployment of I2RS applications, I2RS clients, and I2RS agents can be located locally in a closed environment or distributed over open networks. The normal case for routing system management is over an open environment. Even in a closed environment, access control policies should be carefully defined to be able to, in the future, carefully extend the I2RS plane to remote applications or remote I2RS clients. - [I-D.ietf-i2rs-protocol-security-requirements] defines the security - requirements of the I2RS protocol between the I2RS client and the - I2RS agent over a secure transport. This section focuses on I2RS - access control architecture (section 4.1), access control policies of - the I2RS agent (section 4.2), the I2RS client (section 4.3), and the - application (section 4.4). + [RFC8241] defines the security requirements of the I2RS protocol + between the I2RS client and the I2RS agent over a secure transport. + This section focuses on I2RS access control architecture (section + 4.1), access control policies of the I2RS agent (section 4.2), the + I2RS client (section 4.3), and the application (section 4.4). 4.1. I2RS Access Control Architecture Overview: Applications access the routing system resource via numerous intermediate nodes. The application communicates with an I2RS client. In some cases, the I2RS client is only associated with a single application attached to one or more agents (case a and case b in figure 4 below). In other cases, the I2RS client may be connected @@ -617,21 +615,21 @@ "Write failure: you do not have write permission", or "Write failure: resource accessed by someone else". This requirement has been written in a generic manner as it relates to the following interactions: o interactions between the application and the I2RS client, o interactions between the I2RS client and the I2RS agent at a content level (Protocol security requirements are described by - [I-D.ietf-i2rs-protocol-security-requirements]), and + [RFC8241]), and o interactions between the I2RS agent and the I2RS routing system (forwarding plane, control plane, and routing plane). 4.1.3. Trust SEC-ENV-REQ 8: In order to provide coherent access control policies enforced by multiple parties (e.g. the I2RS client or the I2RS agent), theses parties should trust each other, and communication between them should also be @@ -898,22 +896,21 @@ can appropriately perform an update according to the priorities associated to the requesting identity and the identity that last updated the resource. SEC-ENV-REQ 25: the I2RS agent should have an "I2RS agent overwrite Policy" that indicates how identities can be prioritized. This requirement is also described in section 7.6 of [RFC7921]. Similar requirements exist for components within the I2RS plane, but this is within the scope of the I2RS protocol security - requirements - [I-D.ietf-i2rs-protocol-security-requirements]. + requirements [RFC8241]. Explanation: If the I2RS application is authenticated to the I2RS client, and the I2RS client is authenticated to the I2RS agent, and the I2RS client uses the opaque secondary identifier to pass an authenticated identifier to the I2RS agent, then this identifier may be used for access control. However, caution should be taken when using this chain of authentication since the secondary identifier is intended in the I2RS protocol only to aid traceability. @@ -921,22 +918,21 @@ From the environment perspective the I2RS agent MUST be aware when the resource has been modified outside the I2RS plane by another plane (management, control, or forwarding). The prioritization between the different planes should set a deterministic policy that allows the collision of two planes (I2RS plane and another plane) to be resolved via an overwrite policy in the I2RS agent. Similar requirements exist for knowledge about identities within the I2RS plane which modify things in the routing system, but this is within the scope of the I2RS protocol's requirements for ephemeral - state [I-D.ietf-i2rs-ephemeral-state] and security requirements - [I-D.ietf-i2rs-protocol-security-requirements]. + state [RFC8242] and security requirements [RFC8241]. 4.2.2. I2RS Client Access Control Policies Overview: The I2RS client access control policies are responsible for authenticating the application managing the privileges for the applications, and enforcing access control to resources by the applications. @@ -1176,64 +1172,64 @@ Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas, Alia Atlas, and Linda Dunbar. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, - . + . [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, - . + . [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, - . + . [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, . + 2016, . [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements for Subscription to YANG Datastores", RFC 7923, DOI 10.17487/RFC7923, June 2016, - . + . - [I-D.ietf-i2rs-protocol-security-requirements] - Hares, S., Migault, D., and J. Halpern, "I2RS Security - Related Requirements", draft-ietf-i2rs-protocol-security- - requirements-17 (work in progress), September 2016. + [RFC8241] Hares, S., Migault, D., and J. Halpern, "Interface to the + Routing System (I2RS) Security-Related Requirements", + RFC 8241, DOI 10.17487/RFC8241, September 2017, + . 9.2. Informative References - [I-D.ietf-i2rs-ephemeral-state] - Haas, J. and S. Hares, "I2RS Ephemeral State - Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in - progress), November 2016. + [RFC8242] Haas, J. and S. Hares, "Interface to the Routing System + (I2RS) Ephemeral State Requirements", RFC 8242, + DOI 10.17487/RFC8242, September 2017, + . [I-D.ietf-netconf-rfc6536bis] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", draft-ietf- - netconf-rfc6536bis-01 (work in progress), March 2017. + netconf-rfc6536bis-05 (work in progress), September 2017. [I-D.ietf-netmod-revised-datastores] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore - Architecture", draft-ietf-netmod-revised-datastores-01 - (work in progress), March 2017. + Architecture", draft-ietf-netmod-revised-datastores-04 + (work in progress), August 2017. Authors' Addresses Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160