--- 1/draft-ietf-i2rs-protocol-security-requirements-06.txt 2016-08-17 09:15:54.268263882 -0700 +++ 2/draft-ietf-i2rs-protocol-security-requirements-07.txt 2016-08-17 09:15:54.296264582 -0700 @@ -1,20 +1,20 @@ I2RS working group S. Hares Internet-Draft Huawei Intended status: Informational D. Migault -Expires: November 25, 2016 J. Halpern +Expires: February 17, 2017 J. Halpern Ericsson - May 24, 2016 + August 16, 2016 I2RS Security Related Requirements - draft-ietf-i2rs-protocol-security-requirements-06 + draft-ietf-i2rs-protocol-security-requirements-07 Abstract This presents 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 @@ -23,21 +23,21 @@ 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 November 25, 2016. + This Internet-Draft will expire on February 17, 2017. Copyright Notice Copyright (c) 2016 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 @@ -74,44 +74,42 @@ 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. 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 - [I-D.ietf-i2rs-architecture] document which solves the problem - described in [I-D.ietf-i2rs-problem-statement]. + [RFC7921] document which solves the problem described in [RFC7920]. [I-D.ietf-i2rs-ephemeral-state] 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 [I-D.ietf-i2rs-traceability] describes the - traceability framework and its requirements for I2RS. The draft - [I-D.ietf-i2rs-pub-sub-requirements] describes the requirements for - I2RS to be able to publish information or have a remote client - subscribe to an information data stream. + priority. The draft [RFC7922] describes the traceability framework + and its requirements for I2RS. The draft [RFC7923] describes the + requirements for I2RS to be able to publish information or have a + remote client subscribe to an information data stream. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 2. Definitions 2.1. Security Definitions 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: access control [RFC4949] defines access control as the following: 1. (I) Protection of system resources against unauthorized access. @@ -120,21 +118,21 @@ 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.) 3. (I) /formal model/ Limitations on interactions between subjects and objects in an information system. 4. (O) "The prevention of unauthorized use of a resource, 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, or human controls to identify or admit personnel with properly authorized access to a SCIF. 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 @@ -156,21 +154,21 @@ data. Data Integrity [RFC4949] states data integrity includes: 1. (I) The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner. [...] 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 [RFC4949] describes data privacy as a synonym for data confidentiality. This I2RS document will utilize data privacy as a synonym for data confidentiality. Identity [RFC4949] (I) The collective aspect of a set of attribute values @@ -220,23 +218,23 @@ [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." Requirements to support a security audit is not covered in this document. - [I-D.ietf-i2rs-traceability] describes traceability for I2RS - interface and the I2RS protocol. Traceability is not equivalent - to a security audit trail. + [RFC7922] describes traceability for I2RS interface and the I2RS + protocol. Traceability is not equivalent to a security audit + trail. Trust [RFC4949] 1. (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 @@ -276,23 +274,23 @@ 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. I2RS multi-message atomicity 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). + supported in order to simplify 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). I2RS transaction is a unit of I2RS functionality. Some examples of I2RS transactions are: * The I2RS client issues a read request to a I2RS agent, and the I2RS Agent responding to the read request * The I2RS client issues a write of ephemeral configuration @@ -308,25 +306,25 @@ the I2RS Agent sets up to send the events. * An I2RS agent sends events to an I2RS Client on an existing connection. An I2RS action may require multiple I2RS messages in order to complete a transation. I2RS secondary identifier - The I2RS architecture document [I-D.ietf-i2rs-architecture] - 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. + The I2RS architecture document [RFC7921] 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. 3. Security-Related Requirements 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 @@ -336,22 +334,21 @@ 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. 3.1. Mutual authentication of an I2RS client and an I2RS Agent - The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following - requirements: + The I2RS architecture [RFC7921] sets the following requirements: o 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. o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for mutual identification of the I2RS client and I2RS agent. 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 @@ -467,45 +464,43 @@ Requirements SEC-REQ-14 and SEC-REQ-15 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. SEC-REQ-16: The I2RS message traceability and notification - requirements requirements found in [I-D.ietf-i2rs-traceability] and - - [I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in - communication channel that is non-secure to trace or notify about - potential security issues. + requirements requirements found in [RFC7922] and [RFC7923] SHOULD be + supported in communication channel that is non-secure to trace or + notify about potential security issues. 3.5. Role-Based Data Model Security - The I2RS Architecture [I-D.ietf-i2rs-architecture] 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. + The I2RS Architecture [RFC7921] 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. 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. SEC-REQ-18: 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. + the I2RS architecture [RFC7921] 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. 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. Please note the security of the application to I2RS client connection @@ -541,83 +536,81 @@ 6. Security Considerations This is a document about security requirements for the I2RS protocol and data modules. The whole document is security considerations. 7. 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 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, . + [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, + . + 7.2. Informative References [I-D.ietf-i2rs-ephemeral-state] Haas, J. and S. Hares, "I2RS Ephemeral State - Requirements", draft-ietf-i2rs-ephemeral-state-06 (work in - progress), May 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. + Requirements", draft-ietf-i2rs-ephemeral-state-15 (work in + progress), July 2016. [I-D.ietf-i2rs-security-environment-reqs] Migault, D., Halpern, J., and S. Hares, "I2RS Environment Security Requirements", draft-ietf-i2rs-security- 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", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . + [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, . + + [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements + for Subscription to YANG Datastores", RFC 7923, + DOI 10.17487/RFC7923, June 2016, + . + Authors' Addresses Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Email: shares@ndzh.com + Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC HAP 2N2 Canada Email: daniel.migault@ericsson.com - Joel Halpern Ericsson US Email: joel.halpern@ericsson.com