idnits 2.17.1 draft-ietf-i2rs-protocol-security-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 31, 2015) is 3037 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-12 ** Downref: Normative reference to an Informational draft: draft-ietf-i2rs-architecture (ref. 'I-D.ietf-i2rs-architecture') == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-08 == Outdated reference: A later version (-09) exists of draft-ietf-i2rs-pub-sub-requirements-03 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-traceability-05 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group S. Hares 3 Internet-Draft Huawei 4 Intended status: Standards Track D. Migault 5 Expires: July 3, 2016 J. Halpern 6 Ericsson 7 December 31, 2015 9 I2RS Security Related Requirements 10 draft-ietf-i2rs-protocol-security-requirements-02 12 Abstract 14 This presents security-related requirements for the I2RS protocol for 15 mutual authentication, transport protocols, data transfer and 16 transactions. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 3, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Security-Related Requirements . . . . . . . . . . . . . . . . 5 56 2.1. Mutual authentication of I2RS client and I2RS Agent . . . 5 57 2.2. Transport Requirements Based on Mutual Authentication . . 6 58 2.3. Data Confidentiality Requirements . . . . . . . . . . . . 7 59 2.4. Data Integrity Requirements . . . . . . . . . . . . . . . 7 60 2.5. Role-Based Data Model Security . . . . . . . . . . . . . 8 61 3. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 6.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 The Interface to the Routing System (I2RS) provides read and write 72 access to information and state within the routing process. The I2RS 73 client interacts with one or more I2RS agents to collect information 74 from network routing systems. 76 This document describes the requirements for the I2RS protocol in the 77 security-related areas of mutual authentication of the I2RS client 78 and agent, the transport protocol carrying the I2RS protocol 79 messages, and the atomicity of the transactions. These requirements 80 align with the description of the I2RS architecture found in 81 [I-D.ietf-i2rs-architecture] document which solves the problem 82 described in [I-D.ietf-i2rs-problem-statement]. 84 [I-D.haas-i2rs-ephemeral-state-reqs] discusses I2RS roles-based write 85 conflict resolution in the ephemeral data store using the I2RS Client 86 Identity, I2RS Secondary Identity and priority. The draft 87 [I-D.ietf-i2rs-traceability] describes the traceability framework and 88 its requirements for I2RS. The draft 89 [I-D.ietf-i2rs-pub-sub-requirements] describes the requirements for 90 I2RS to be able to publish information or have a remote client 91 subscribe to an information data stream. 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 1.2. Definitions 101 This document utilizes the definitions found in the following drafts: 102 [RFC4949], and [I-D.ietf-i2rs-architecture] 104 Specifically, this document utilizes the following definitions: 106 access control 108 [RFC4949] defines access control as the following: 110 1)(I))protection of system resources against unauthorized use; 112 2)(I)process by which use of system resources is regulated 113 according to a security policy and is permitted only by 114 authorized entities (users, programs, processes, or other 115 systems) according to that policy; 117 3)(I) (formal model) Limitations on interactions between 118 subjects and objects in an information system; 120 4)(O) "The prevention of unauthorized use of a resource, 121 including the prevention of use of a resource in an 122 unauthorized manner."; 124 5.(O) /U.S. Government/ A system using physical, electronic, 125 or human controls to identify or admit personnel with properly 126 authorized access to a SCIF. 128 Authentication 130 [RFC4949] describes authentication as the process of verifying 131 (i.e., establishing the truth of) an attribute value claimed by or 132 for a system entity or system resource. Authentication has two 133 steps: identify and verify. 135 Data Confidentiality 137 [RFC4949] describes data confidentiality as having two properties: 138 a) data is not disclosed to system entities unless they have been 139 authorized to know, and b) data is not disclosed to unauthorized 140 individuals, entities or processes. The key point is that 141 confidentiality implies that the originator has the ability to 142 authorize where the information goes. Confidentiality is 143 important for both read and write scope of the data. 145 Data Integrity 147 [RFC4949] states data integrity includes 149 1. (I)The property that data has not been changed, destroyed, 150 or 152 2. (O) "The property that information has not been modified or 153 destroyed in an unauthorized manner." 155 Data Privacy 157 [RFC4949] describes data privacy as a synonym for data 158 confidentiality. This I2RS document will utilize data privacy as 159 a synonym for data confidentiality. 161 Mutual Authentication 163 [RFC4949] implies that mutual authentication exists between two 164 interacting system entities. Mutual authentication in I2RS 165 implies that both sides move from a state of mutual suspicion to 166 mutually authenticated communication after each system has been 167 identified and validated by its peer system. 169 role 171 [RFC4949] describes role as: 173 1) (I) A job function or employment position to which people or 174 other system entities may be assigned in a system. (See: role- 175 based access control. Compare: duty, billet, principal, user.) 177 2) (O) /Common Criteria/ A pre-defined set of rules 178 establishing the allowed interactions between a user and the 179 TOE. 181 The I2RS uses the common criteria definition. 183 role 185 [RFC4949] describes role-based access control as: (I) A form of 186 identity-based access control wherein the system entities that are 187 identified and controlled are functional positions in an 188 organization or process. 190 Security audit trail 192 [RFC4949] (page 254) describes a security audit trail as a 193 chronological record of system activities that is sufficient to 194 enable the reconstruction and examination of the sequence 195 environments and activities surrounding or leading to an 196 operation, procedure, or event in a security-relevant transaction 197 from inception to final results. Requirements to support a 198 security audit is not covered in this document. The draft 199 [I-D.ietf-i2rs-traceability] describes traceability for I2RS 200 interface and protocol. Traceability is not equivalent to a 201 security audit trail. 203 I2RS the following phrase that incorporates an [RFC4949] definition: 205 I2RS protocol data integrity 207 The transfer of data via the I2RS protocol has the property of 208 data integrity described in [RFC4949]. 210 2. Security-Related Requirements 212 The security for the I2RS protocol requires mutually authenticated 213 I2RS clients and I2RS agents. The I2RS client and I2RS agent using 214 the I2RS protocol MUST be able to exchange data over a secure 215 transport, but some functions may operate on non-secure transport. 216 The I2RS protocol MUST BE able to provide atomicity of a transaction, 217 but it is not required to have multi-message atomicity and roll-back 218 mechanism transactions. Multiple messages transactions may be 219 impacted by the interdependency of data. This section discusses 220 these details of these security requirements. 222 2.1. Mutual authentication of I2RS client and I2RS Agent 224 The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following 225 requirements: 227 o SEC-REQ-01: All I2RS clients and I2RS agents MUST have at least 228 one unique identifier that uniquely identifies each party. 230 o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for 231 mutual identification of the I2RS client and I2RS agent. 233 o SEC-REQ-03:An I2RS agent, upon receiving an I2RS message from a 234 I2RS client, MUST confirm that the I2RS client has a valid 235 identifier. 237 o SEC-REQ-04: The I2RS client, upon receiving an I2RS message from 238 an I2RS agent, MUST confirm the I2RS agent has a valid identifier 239 . 241 o SEC-REQ-05: Identifier distribution and the loading of these 242 identifiers into I2RS agent and I2RS Client SHOULD occur outside 243 the I2RS protocol. 245 o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF 246 or private) will distribute or load identifiers so that the I2RS 247 client/agent has these identifiers prior to the I2RS protocol 248 establishing a connection between I2RS client and I2RS agent. 250 o SEC-REQ-07: Each Identifier MUST be linked to one priority 252 o SEC-REQ-08: Each Identifier is associated with one secondary 253 identifier during a particular read/write sequence, but the 254 secondary identifier may vary during the time a connection between 255 the I2RS client and I2RS agent is active. The variance of the 256 secondary identifier allows the I2RS client to be associated with 257 multiple applications and pass along an identifier for these 258 applications in the secondary identifier. 260 2.2. Transport Requirements Based on Mutual Authentication 262 SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a 263 secure transport and optionally MAY be able to transfer data over a 264 non-secure transport. A secure transport MUST provide data 265 confidentiality, data integrity, and replay prevention. 267 Note:The non-secure transport can be used for publishing telemetry 268 data that was specifically indicated to non-confidential in the data 269 model. The configuration of ephemeral data in the I2RS Agent by the 270 I2RS client SHOULD be done over a secure transport. It is 271 anticipated that the passing of most I2RS ephemeral state operational 272 status SHOULD be done over a secure transport. Data models SHOULD 273 clearly annotate what data nodes can be passed over an insecure 274 connection. The default transport is a secure transport. 276 SEC-REQ-10: A secure transport MUST be associated with a key 277 management solution that can guarantee that only the entities having 278 sufficient privileges can get the keys to encrypt/decrypt the 279 sensitive data. Per BCP107 [RFC4107] this key management system 280 SHOULD be automatic, but MAY BE manual if the following constraints 281 from BCP107: 283 a)environment has limited bandwidth or high round-trip times, 285 b)the information being protected has a low value and 287 c)the total volume over the entire lifetime of the long-term 288 session key will be very low, 289 d)the scale of the deployment is limited. 291 Most I2RS environments (I2RS Client - I2S Agents) will not have the 292 environment described by BCP107 [RFC4107] but a few I2RS use cases 293 required limited non-secure light-weight telemetry messages that have 294 these requirements. An I2RS data model must indicate which portions 295 can be served by manual key management. 297 SEC-REQ-11: The I2RS protocol MUST be able to support multiple secure 298 transport sessions providing protocol and data communication between 299 an I2RS Agent and an I2RS client. However, a single I2RS Agent to 300 I2RS client connection MAY elect to use a single secure transport 301 session or a single non-secure transport session. 303 SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement 304 mechanisms that mitigate DoS attacks 306 2.3. Data Confidentiality Requirements 308 SEC-REQ-13: In a critical infrastructure, certain data within routing 309 elements is sensitive and read/write operations on such data MUST be 310 controlled in order to protect its confidentiality. For example, 311 most carriers do not want a router's configuration and data flow 312 statistics known by hackers or their competitors. While carriers may 313 share peering information, most carriers do not share configuration 314 and traffic statistics. To achieve this, access control to sensitive 315 data needs to be provided, and the confidentiality protection on such 316 data during transportation needs to be enforced. 318 2.4. Data Integrity Requirements 320 SEC-REQ-14: An integrity protection mechanism for I2RS SHOULD be able 321 to ensure the following: 1) the data being protected is not modified 322 without detection during its transportation and 2) the data is 323 actually from where it is expected to come from 3) the data is not 324 repeated from some earlier interaction of the protocol. That is, 325 when both confidentiality and integrity of data is properly 326 protected, it is possible to ensure that encrypted data is not 327 modified or replayed without detection. 329 SEC-REQ-15: The integrity that the message data is not repeated means 330 that I2RS client to I2RS agent transport SHOULD protect against 331 replay attack 333 Requirements SEC-REQ-13 and SEC-REQ-14 are SHOULD requirements only 334 because it is recognized that some I2RS Client to I2RS agent 335 communication occurs over a non-secure channel. The I2RS client to 336 I2RS agent over a secure channel would implement these features. In 337 order to provide some traceability or notification for the non-secure 338 protocol, SEC-REQ-16 suggests traceability and notification are 339 important to include for any non-secure protocol. 341 SEC-REQ-16: The I2RS message traceability and notification 342 requirements requirements found in [I-D.ietf-i2rs-traceability] and 343 [I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in 344 communication channel that is non-secure to trace or notify about 345 potential security issues 347 2.5. Role-Based Data Model Security 349 The [I-D.ietf-i2rs-architecture] defines a role or security role as 350 specifying read, write, or notification access by a I2RS client to 351 data within an agent's data model. 353 SEC-REQ-17: The rules around what role is permitted to access and 354 manipulate what information plus a secure transport (which protects 355 the data in transit) SHOULD ensure that data of any level of 356 sensitivity is reasonably protected from being observed by those 357 without permission to view it, so that privacy requirements are met. 359 SEC-REQ-18: Role security MUST work when multiple transport 360 connections are being used between the I2RS client and I2RS agent as 361 the I2RS architecture [I-D.ietf-i2rs-architecture] states. These 362 transport message streams may start/stop without affecting the 363 existence of the client/agent data exchange. TCP supports a single 364 stream of data. SCTP [RFC4960] provides security for multiple 365 streams plus end-to-end transport of data. 367 SEC-REQ-19: I2RS clients MAY be used by multiple applications to 368 configure routing via I2RS agents, receive status reports, turn on 369 the I2RS audit stream, or turn on I2RS traceability. Application 370 software using I2RS client functions may host several multiple secure 371 identities, but each connection will use only one identifier with one 372 priority. Therefore, the security of each I2RS Client to I2RS Agent 373 connection is unique. 375 Please note the security of the application to I2RS client connection 376 is outside of the I2RS protocol or I2RS interface. 378 3. Acknowledgement 380 The author would like to thank Wes George, Ahmed Abro, Qin Wu, Eric 381 Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia 382 Atlas, and Jeff Haas for their contributions to the I2RS security 383 requirements discussion and this document. 385 4. IANA Considerations 387 This draft includes no request to IANA. 389 5. Security Considerations 391 This is a document about security requirements for the I2RS protocol 392 and data modules. The whole document is security considerations. 394 6. References 396 6.1. Normative References 398 [I-D.ietf-i2rs-architecture] 399 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 400 Nadeau, "An Architecture for the Interface to the Routing 401 System", draft-ietf-i2rs-architecture-12 (work in 402 progress), December 2015. 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, 406 DOI 10.17487/RFC2119, March 1997, 407 . 409 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 410 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 411 June 2005, . 413 6.2. Informative References 415 [I-D.haas-i2rs-ephemeral-state-reqs] 416 Haas, J., "I2RS Ephemeral State Requirements", draft-haas- 417 i2rs-ephemeral-state-reqs-00 (work in progress), May 2015. 419 [I-D.ietf-i2rs-problem-statement] 420 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 421 Routing System Problem Statement", draft-ietf-i2rs- 422 problem-statement-08 (work in progress), December 2015. 424 [I-D.ietf-i2rs-pub-sub-requirements] 425 Voit, E., Clemm, A., and A. Prieto, "Requirements for 426 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 427 requirements-03 (work in progress), October 2015. 429 [I-D.ietf-i2rs-traceability] 430 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 431 the Routing System (I2RS) Traceability: Framework and 432 Information Model", draft-ietf-i2rs-traceability-05 (work 433 in progress), December 2015. 435 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 436 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 437 . 439 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 440 RFC 4960, DOI 10.17487/RFC4960, September 2007, 441 . 443 Authors' Addresses 445 Susan Hares 446 Huawei 447 7453 Hickory Hill 448 Saline, MI 48176 449 USA 451 Email: shares@ndzh.com 453 Daniel Migault 454 Ericsson 455 8400 boulevard Decarie 456 Montreal, QC HAP 2N2 457 Canada 459 Email: daniel.migault@ericsson.com 461 Joel Halpern 462 Ericsson 463 US 465 Email: joel.halpern@ericsson.com