idnits 2.17.1 draft-ietf-i2rs-protocol-security-requirements-03.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 (March 9, 2016) is 2970 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) == Missing Reference: 'I7498-2' is mentioned on line 165, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-13 ** Downref: Normative reference to an Informational draft: draft-ietf-i2rs-architecture (ref. 'I-D.ietf-i2rs-architecture') == Outdated reference: A later version (-23) exists of draft-ietf-i2rs-ephemeral-state-03 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-10 == Outdated reference: A later version (-09) exists of draft-ietf-i2rs-pub-sub-requirements-05 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-traceability-07 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 7 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: September 10, 2016 J. Halpern 6 Ericsson 7 March 9, 2016 9 I2RS Security Related Requirements 10 draft-ietf-i2rs-protocol-security-requirements-03 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 September 10, 2016. 35 Copyright Notice 37 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . 3 54 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Security Definitions . . . . . . . . . . . . . . . . . . 3 56 2.2. I2RS Specific Definitions . . . . . . . . . . . . . . . . 6 57 3. Security-Related Requirements . . . . . . . . . . . . . . . . 7 58 3.1. Mutual authentication of an I2RS client and an I2RS Agent 8 59 3.2. Transport Requirements Based on Mutual Authentication . . 8 60 3.3. Data Confidentiality Requirements . . . . . . . . . . . . 10 61 3.4. Data Integrity Requirements . . . . . . . . . . . . . . . 10 62 3.5. Role-Based Data Model Security . . . . . . . . . . . . . 11 63 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 68 7.2. Informative References . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 The Interface to the Routing System (I2RS) provides read and write 74 access to information and state within the routing process. The I2RS 75 client interacts with one or more I2RS agents to collect information 76 from network routing systems. 78 This document describes the requirements for the I2RS protocol in the 79 security-related areas of mutual authentication of the I2RS client 80 and agent, the transport protocol carrying the I2RS protocol 81 messages, and the atomicity of the transactions. These requirements 82 align with the description of the I2RS architecture found in 83 [I-D.ietf-i2rs-architecture] document which solves the problem 84 described in [I-D.ietf-i2rs-problem-statement]. 86 [I-D.ietf-i2rs-ephemeral-state] discusses I2RS roles-based write 87 conflict resolution in the ephemeral data store using the I2RS Client 88 Identity, I2RS Secondary Identity and priority. The draft 89 [I-D.ietf-i2rs-traceability] describes the traceability framework and 90 its requirements for I2RS. The draft 91 [I-D.ietf-i2rs-pub-sub-requirements] describes the requirements for 92 I2RS to be able to publish information or have a remote client 93 subscribe to an information data stream. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Definitions 103 2.1. Security Definitions 105 This document utilizes the definitions found in the following 106 documents: [RFC4949] and [I-D.ietf-i2rs-architecture] 108 Specifically, this document utilizes the following definitions: 110 access control 112 [RFC4949] defines access control as the following: 114 1. (I) Protection of system resources against unauthorized 115 access. 117 2. (I) A process by which use of system resources is regulated 118 according to a security policy and is permitted only by 119 authorized entities (users, programs, processes, or other 120 systems) according to that policy. (See: access, access 121 control service, computer security, discretionary access 122 control, mandatory access control, role-based access control.) 124 3. (I) /formal model/ Limitations on interactions between 125 subjects and objects in an information system. 127 4. (O) "The prevention of unauthorized use of a resource, 128 including the prevention of use of a resource in an 129 unauthorized manner." [I7498-2] 131 5. (O) /U.S. Government/ A system using physical, electronic, 132 or human controls to identify or admit personnel with properly 133 authorized access to a SCIF. 135 Authentication 137 [RFC4949] describes authentication as the process of verifying 138 (i.e., establishing the truth of) an attribute value claimed by or 139 for a system entity or system resource. Authentication has two 140 steps: identify and verify. 142 Data Confidentiality 144 [RFC4949] describes data confidentiality as having two properties: 146 a) Data is not disclosed to system entities unless they have 147 been authorized to know the data, and 149 b) Data is not disclosed to unauthorized individuals, entities 150 or processes. 152 The key point is that confidentiality implies that the originator 153 has the ability to authorize where the information goes. 154 Confidentiality is important for both read and write scope of the 155 data. 157 Data Integrity 159 [RFC4949] states data integrity includes: 161 1. (I) The property that data has not been changed, destroyed, 162 or lost in an unauthorized or accidental manner. [...] 164 2. (O) "The property that information has not been modified or 165 destroyed in an unauthorized manner." [I7498-2] 167 Data Privacy 169 [RFC4949] describes data privacy as a synonym for data 170 confidentiality. This I2RS document will utilize data privacy as 171 a synonym for data confidentiality. 173 Identity 175 [RFC4949] (I) The collective aspect of a set of attribute values 176 (i.e., a set of characteristics) by which a system user or other 177 system entity is recognizable or known. (See: authenticate, 178 registration. Compare: identifier.) 180 Identifier 182 [RFC4949] (I) A data object -- often, a printable, non-blank 183 character string -- that definitively represents a specific 184 identity of a system entity, distinguishing that identity from all 185 others. (Compare: identity.) 187 Mutual Authentication 189 [RFC4949] implies that mutual authentication exists between two 190 interacting system entities. 192 Mutual authentication in I2RS implies that both sides move from a 193 state of mutual suspicion to to mutual authentication to trusted 194 mutual communication after each system has been identified and 195 validated by its peer system. 197 role 199 [RFC4949] describes role as: 201 1. (I) A job function or employment position to which people 202 or other system entities may be assigned in a system. [...] 204 2. (O) /Common Criteria/ A pre-defined set of rules 205 establishing the allowed interactions between a user and the 206 TOE. 208 The I2RS uses the common criteria definition. 210 role-based access control 212 [RFC4949] describes role-based access control as: "A form of 213 identity-based access control wherein the system entities that are 214 identified and controlled are functional positions in an 215 organization or process." 217 security audit trail 219 [RFC4949] describes a security audit trail as "A chronological 220 record of system activities that is sufficient to enable the 221 reconstruction and examination of the sequence environments and 222 activities surrounding or leading to an operation, procedure, or 223 event in a security-relevant transaction from inception to final 224 results." 226 Requirements to support a security audit is not covered in this 227 document. 229 [I-D.ietf-i2rs-traceability] describes traceability for I2RS 230 interface and the I2RS protocol. Traceability is not equivalent 231 to a security audit trail. 233 Trust 235 [RFC4949] 237 1. (I) /information system/ A feeling of certainty (sometimes 238 based on inconclusive evidence) either (a) that the system 239 will not fail or (b) that the system meets its specifications 240 (i.e., the system does what it claims to do and does not 241 perform unwanted functions). (See: trust level, trusted 242 system, trustworthy system. Compare: assurance.) 244 2. . (I) /PKI/ A relationship between a certificate user and a CA 245 in which the user acts according to the assumption that the CA 246 creates only valid digital certificates. (Also referred as 247 "trusted" in [RFC4949].) 249 2.2. I2RS Specific Definitions 251 I2RS protocol data integrity 253 The transfer of data via the I2RS protocol has the property of 254 data integrity described in [RFC4949]. 256 I2RS component protocols 258 Protocols which are combined to create the I2RS protocol. 260 I2RS Higher-level protocol 262 The I2RS protocol exists as a higher-level protocol which combines 263 combination of other protocols (NETCONF, RESTCONF, IPFIX, and 264 others) within a specific I2RS client-agent relationship with a 265 specific trust for ephemeral configurations, event, tracing, 266 actions, and data flow interactions. The protocols included in 267 the I2RS protocol protocol are defined as I2RS component 268 protocols. 270 I2RS message 272 is a complete data message of one of the I2RS component protocols. 273 The I2RS component protocols may require multiple IP-packets to 274 send one protocol message. 276 I2RS multi-message atomicity 278 An I2RS operation (read, write, event, action) must be contained 279 within one I2RS message. Each I2RS operation must be atomic. 280 While it is possible to have an I2RS operation which is contained 281 in multiple I2RS (E.g. write in multiple messages), this is not 282 supported in order to simply the first version of I2RS. Multiple- 283 message atomicity of I2RS operations would be used in a roll-back 284 of a grouping of commands (e.g. multiple writes). 286 I2RS transaction 287 is a unit of I2RS functionality. Some examples of I2RS 288 transactions are: 290 * The I2RS client issuing a read request to a I2RS agent, and the 291 I2RS Agent responding to the read request 293 * The I2RS client issue a write of ephemeral configuration values 294 into a data model, followed by the I2RS agent response to the 295 write. 297 * An I2RS client may issue an action request, the I2RS agent 298 responds to the action-request, and then responds when action 299 is complete. Actions can be single step processes or multiple 300 step process. 302 * An I2RS client requests to receive an event notification, and 303 the I2RS Agent sets up to send the events. 305 * An I2RS agent sends events to an I2RS Client on an existing 306 connection. 308 An I2RS action may require multiple I2RS messages in order to 309 complete a transation. 311 I2RS secondary identifier 313 the I2RS architecture document [I-D.ietf-i2rs-architecture] 314 defines a secondary identity as the entity of some non-I2RS entity 315 (e.g. application) which has requested a particular I2RS client 316 perform an operation. The I2RS secondary identifier represents 317 this identity so it may be distinguished from all others. 319 3. Security-Related Requirements 321 The security for the I2RS protocol requires mutually authenticated 322 I2RS clients and I2RS agents. The I2RS client and I2RS agent using 323 the I2RS protocol MUST be able to exchange data over a secure 324 transport, but some functions may operate on a non-secure transport. 325 The I2RS protocol MUST be able to provide atomicity of an I2RS 326 transaction, but it is not required to have multi-message atomicity 327 and roll-back mechanism transactions. Multiple messages transactions 328 may be impacted by the interdependency of data. This section 329 discusses the details of these security requirements. 331 3.1. Mutual authentication of an I2RS client and an I2RS Agent 333 The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following 334 requirements: 336 o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an 337 identity, and at least one unique identifier that uniquely 338 identifies each party in the I2RS protocol context. 340 o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for 341 mutual identification of the I2RS client and I2RS agent. 343 o SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a 344 I2RS client, MUST confirm that the I2RS client has a valid 345 identifier. 347 o SEC-REQ-04: The I2RS client, upon receiving an I2RS message from 348 an I2RS agent, MUST confirm the I2RS agent has a valid identifier. 350 o SEC-REQ-05: Identifier distribution and the loading of these 351 identifiers into I2RS agent and I2RS Client SHOULD occur outside 352 the I2RS protocol. 354 o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF 355 or private) will distribute or load identifiers so that the I2RS 356 client/agent has these identifiers prior to the I2RS protocol 357 establishing a connection between I2RS client and I2RS agent. 359 o SEC-REQ-07: Each Identifier MUST have just one priority. 361 o SEC-REQ-08: Each Identifier is associated with one secondary 362 identifier during a particular I2RS transaction (e.g. read/write 363 sequence), but the secondary identifier may vary during the time a 364 connection between the I2RS client and I2RS agent is active. 365 Since a single I2RS client may be use by multiple applications, 366 the secondary identifier may vary as the I2RS client is utilize by 367 different application each of whom have a unique secondary 368 identity and identifier. 370 3.2. Transport Requirements Based on Mutual Authentication 372 SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a 373 secure transport and optionally MAY be able to transfer data over a 374 non-secure transport. A secure transport MUST provide data 375 confidentiality, data integrity, and replay prevention. 377 The default I2RS transport is a secure transport. 379 A non-secure transport can be can be used for publishing telemetry 380 data or other operational state that was specifically indicated to 381 non-confidential in the data model in the Yang syntax. 383 The configuration of ephemeral data in the I2RS Agent by the I2RS 384 client SHOULD be done over a secure transport. It is anticipated 385 that the passing of most I2RS ephemeral state operational status 386 SHOULD be done over a secure transport. As 387 [I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate 388 whether the transport exchanging the data between I2RS client and 389 I2RS agent is secure or insecure. The default mode of transport is 390 secure so data models SHOULD clearly annotate what data nodes can be 391 passed over an insecure connection. 393 SEC-REQ-10: A secure transport MUST be associated with a key 394 management solution that can guarantee that only the entities having 395 sufficient privileges can get the keys to encrypt/decrypt the 396 sensitive data. Per BCP107 [RFC4107] this key management system 397 SHOULD be automatic, but MAY be manual in the following scenarios: 399 a) The environment has limited bandwidth or high round-trip times. 401 b) The information being protected has low value. 403 c) The total volume of traffic over the entire lifetime of the 404 long-term session key will be very low. 406 d) The scale of the deployment is limited. 408 Most I2RS environments (Clients and Agents) will not have the 409 environment described by BCP107 [RFC4107] but a few I2RS use cases 410 required limited non-secure light-weight telemetry messages that have 411 these requirements. An I2RS data model must indicate which portions 412 can be served by manual key management. 414 SEC-REQ-11: The I2RS protocol MUST be able to support multiple secure 415 transport sessions providing protocol and data communication between 416 an I2RS Agent and an I2RS client. However, a single I2RS Agent to 417 I2RS client connection MAY elect to use a single secure transport 418 session or a single non-secure transport session. 420 SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement 421 mechanisms that mitigate DoS attacks 423 3.3. Data Confidentiality Requirements 425 SEC-REQ-13: In a critical infrastructure, certain data within routing 426 elements is sensitive and read/write operations on such data MUST be 427 controlled in order to protect its confidentiality. For example, 428 most carriers do not want a router's configuration and data flow 429 statistics known by hackers or their competitors. While carriers may 430 share peering information, most carriers do not share configuration 431 and traffic statistics. To achieve this, access control to sensitive 432 data needs to be provided, and the confidentiality protection on such 433 data during transportation needs to be enforced. 435 3.4. Data Integrity Requirements 437 SEC-REQ-14: An integrity protection mechanism for I2RS SHOULD be able 438 to ensure the following: 440 1) The data being protected is not modified without detection 441 during its transportation and 443 2) The data is actually from where it is expected to come from 445 3) The data is not repeated from some earlier interaction of the 446 protocol. That is, when both confidentiality and integrity of 447 data is properly protected, it is possible to ensure that 448 encrypted data is not modified or replayed without detection. 450 SEC-REQ-15: The integrity that the message data is not repeated means 451 that I2RS client to I2RS agent transport SHOULD protect against 452 replay attack 454 Requirements SEC-REQ-13 and SEC-REQ-14 are SHOULD requirements only 455 because it is recognized that some I2RS Client to I2RS agent 456 communication occurs over a non-secure channel. The I2RS client to 457 I2RS agent over a secure channel would implement these features. In 458 order to provide some traceability or notification for the non-secure 459 protocol, SEC-REQ-16 suggests traceability and notification are 460 important to include for any non-secure protocol. 462 SEC-REQ-16: The I2RS message traceability and notification 463 requirements requirements found in [I-D.ietf-i2rs-traceability] and 464 [I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in 465 communication channel that is non-secure to trace or notify about 466 potential security issues. 468 3.5. Role-Based Data Model Security 470 The I2RS Architecture [I-D.ietf-i2rs-architecture] defines a role or 471 security role as specifying read, write, or notification access by a 472 I2RS client to data within an agent's data model. 474 SEC-REQ-17: The rules around what role is permitted to access and 475 manipulate what information plus a secure transport (which protects 476 the data in transit) SHOULD ensure that data of any level of 477 sensitivity is reasonably protected from being observed by those 478 without permission to view it, so that privacy requirements are met. 480 SEC-REQ-18: Role security MUST work when multiple transport 481 connections are being used between the I2RS client and I2RS agent as 482 the I2RS architecture [I-D.ietf-i2rs-architecture] states. These 483 transport message streams may start/stop without affecting the 484 existence of the client/agent data exchange. TCP supports a single 485 stream of data. SCTP [RFC4960] provides security for multiple 486 streams plus end-to-end transport of data. 488 SEC-REQ-19: I2RS clients MAY be used by multiple applications to 489 configure routing via I2RS agents, receive status reports, turn on 490 the I2RS audit stream, or turn on I2RS traceability. Application 491 software using I2RS client functions may host multiple secure 492 identities, but each connection will use only one identifier with one 493 priority. Therefore, the security of each I2RS Client to I2RS Agent 494 connection is unique. 496 Please note the security of the application to I2RS client connection 497 is outside of the I2RS protocol or I2RS interface. 499 4. Acknowledgement 501 The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric 502 Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia 503 Atlas, and Jeff Haas for their contributions to the I2RS security 504 requirements discussion and this document. The authors would like to 505 thank Bob Moskowitz for his review of the requirements. 507 5. IANA Considerations 509 This draft includes no request to IANA. 511 6. Security Considerations 513 This is a document about security requirements for the I2RS protocol 514 and data modules. The whole document is security considerations. 516 7. References 518 7.1. Normative References 520 [I-D.ietf-i2rs-architecture] 521 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 522 Nadeau, "An Architecture for the Interface to the Routing 523 System", draft-ietf-i2rs-architecture-13 (work in 524 progress), February 2016. 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, 528 DOI 10.17487/RFC2119, March 1997, 529 . 531 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 532 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 533 June 2005, . 535 7.2. Informative References 537 [I-D.ietf-i2rs-ephemeral-state] 538 Haas, J. and S. Hares, "I2RS Ephemeral State 539 Requirements", draft-ietf-i2rs-ephemeral-state-03 (work in 540 progress), March 2016. 542 [I-D.ietf-i2rs-problem-statement] 543 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 544 Routing System Problem Statement", draft-ietf-i2rs- 545 problem-statement-10 (work in progress), February 2016. 547 [I-D.ietf-i2rs-pub-sub-requirements] 548 Voit, E., Clemm, A., and A. Prieto, "Requirements for 549 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 550 requirements-05 (work in progress), February 2016. 552 [I-D.ietf-i2rs-traceability] 553 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 554 the Routing System (I2RS) Traceability: Framework and 555 Information Model", draft-ietf-i2rs-traceability-07 (work 556 in progress), February 2016. 558 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 559 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 560 . 562 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 563 RFC 4960, DOI 10.17487/RFC4960, September 2007, 564 . 566 Authors' Addresses 568 Susan Hares 569 Huawei 570 7453 Hickory Hill 571 Saline, MI 48176 572 USA 574 Email: shares@ndzh.com 576 Daniel Migault 577 Ericsson 578 8400 boulevard Decarie 579 Montreal, QC HAP 2N2 580 Canada 582 Email: daniel.migault@ericsson.com 584 Joel Halpern 585 Ericsson 586 US 588 Email: joel.halpern@ericsson.com