idnits 2.17.1 draft-ietf-i2rs-protocol-security-requirements-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 1, 2015) is 3154 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) == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 428, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-09 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-06 == Outdated reference: A later version (-09) exists of draft-ietf-i2rs-pub-sub-requirements-02 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-06 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-traceability-03 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 9 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: March 4, 2016 J. Halpern 6 Ericsson 7 September 1, 2015 9 I2RS Security Related Requirements 10 draft-ietf-i2rs-protocol-security-requirements-00 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 March 4, 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. Conventions used in this document . . . . . . . . . . . . 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. 83 [I-D.haas-i2rs-ephemeral-state-reqs] discusses I2RS roles-based write 84 conflict resolution in the ephemeral data store using the I2RS Client 85 Identity, I2RS Secondary Identity and priority. The draft 86 [I-D.ietf-i2rs-traceability] describes the traceability framework and 87 its requirements for I2RS. The draft 88 [I-D.ietf-i2rs-pub-sub-requirements] describes the requirements for 89 I2RS to be able to publish information or have a remote client 90 subscribe to an information data stream. 92 1.1. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119] 98 1.2. Definitions 100 This document utilizes the definitions found in the following drafts: 101 [RFC4949], and [I-D.ietf-i2rs-architecture] 103 Specifically, this document utilizes the following definitions: 105 access control 107 [RFC4949] defines access control as the following: 109 1)(I))protection of system resources against unauthorized use; 111 2)(I)process by which use of system resources is regulated 112 according to a security policy and is permitted only by 113 authorized entities (users, programs, processes, or other 114 systems) according to that policy; 116 3)(I) (formal model) Limitations on interactions between 117 subjects and objects in an information system; 119 4)(O) "The prevention of unauthorized use of a resource, 120 including the prevention of use of a resource in an 121 unauthorized manner."; 123 5.(O) /U.S. Government/ A system using physical, electronic, 124 or human controls to identify or admit personnel with properly 125 authorized access to a SCIF. 127 Authentication 129 [RFC4949] describes authentication as the process of verifying 130 (i.e., establishing the truth of) an attribute value claimed by or 131 for a system entity or system resource. Authentication has two 132 steps: identify and verify. 134 Data Confidentiality 136 [RFC4949] describes data confidentiality as having two properties: 137 a) data is not disclosed to system entities unless they have been 138 authorized to know, and b) data is not disclosed to unauthorized 139 individuals, entities or processes. The key point is that 140 confidentiality implies that the originator has the ability to 141 authorize where the information goes. Confidentiality is 142 important for both read and write scope of the data. 144 Data Integrity 146 [RFC4949] states data integrity includes 148 1. (I)The property that data has not been changed, destroyed, 149 or 151 2. (O) "The property that information has not been modified or 152 destroyed in an unauthorized manner." 154 Data Privacy 156 [RFC4949] describes data privacy as a synonym for data 157 confidentiality. This I2RS document will utilize data privacy as 158 a synonym for data confidentiality. 160 Mutual Authentication 162 [RFC4949] implies that mutual authentication exists between two 163 interacting system entities. Mutual authentication in I2RS 164 implies that both sides move from a state of mutual suspicion to 165 mutually authenticated communication afte each system has been 166 identified and validated by its peer system. 168 role 170 [RFC4949] describes role as: 172 1) (I) A job function or employment position to which people or 173 other system entities may be assigned in a system. (See: role- 174 based access control. Compare: duty, billet, principal, user.) 176 2) (O) /Common Criteria/ A pre-defined set of rules 177 establishing the allowed interactions between a user and the 178 TOE. 180 The I2RS uses the common criteria definition. 182 role 184 [RFC4949] describes role-based access control as: (I) A form of 185 identity-based access control wherein the system entities that are 186 identified and controlled are functional positions in an 187 organization or process. 189 Security audit trail 191 [RFC4949] (page 254) describes a security audit trail as a 192 chronological record of system activities that is sufficient to 193 enable the reconstruction and examination of the sequence 194 environments and activities surrounding or leading to an 195 operation, procedure, or event in a security-relevant transaction 196 from inception to final results. Requirements to support a 197 security audit is not covered in this document. The draft 198 [I-D.ietf-i2rs-traceability] describes traceability for I2RS 199 interface and protocol. Traceability is not equivalent to a 200 security audit trail. 202 I2RS the following phrase that incorporates an [RFC4949] definition: 204 I2RS protocol data integrity 206 The transfer of data via the I2RS protocol has the property of 207 data integrity described in [RFC4949]. 209 2. Security-Related Requirements 211 The security for the I2RS protocol requires mutually authenticated 212 I2RS clients and I2RS agents. The I2RS client and I2RS agent using 213 the I2RS protocol MUST be able to exchange data over a secure 214 transport, but some functions may operate on non-secure transport. 215 The I2RS protocol MUST BE able to provide atomicity of a transaction, 216 but it is not required to have multi-message atomicity and rollback 217 mechanism transactions. Multiple messages transactions may be 218 impacted by the interdependency of data. This section discusses 219 these details of these security requirements. 221 2.1. Mutual authentication of I2RS client and I2RS Agent 223 The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following 224 requirements: 226 o SEC-REQ-01: All I2RS clients and I2RS agents MUST have at least 227 one unique identifier that uniquely identifies each party. 229 o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for 230 mutual identification of the I2RS client and I2RS agent. 232 o SEC-REQ-03:An I2RS agent, upon receiving an I2RS message from a 233 I2RS client, MUST confirm that the I2RS client has a valid 234 identifier. 236 o SEC-REQ-04: The I2RS client, upon receiving an I2RS message from 237 an I2RS agent, MUST confirm the I2RS agent's identifier . 239 o SEC-REQ-05: Identifier distribution and the loading of these 240 identifiers into I2RS agent and I2RS Client SHOULD occur outside 241 the I2RS protocol. 243 o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF 244 or private) will distribute or load identifiers so that the I2RS 245 client/agent has these identifiers prior to the I2RS protocol 246 establishing a connection between I2RS client and I2RS agent. 248 o SEC-REQ-07: Each Identifier MUST be linked to one priority 250 o SEC-REQ-08: Each Identifier is associated with one secondary 251 identifier during a particular read/write sequence, but the 252 secondary identifier may vary during the time a connection between 253 the I2RS client and I2RS agent is active. The variance of the 254 secondary identifier allows the I2RS client to be associated with 255 multiple applications and pass along an identifier for these 256 applications in the secondary identifier. 258 2.2. Transport Requirements Based on Mutual Authentication 260 SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a 261 secure transport and optionally be able to transfer data over a non- 262 secure transport. A secure transport MUST provide data 263 confidentiality, data integrity, and replay prevention. 265 Note:The non-secure transport be used for publishing telemetry data 266 that was specifically indicated to non-confidential in the data 267 model. The configuration of ephemeral data in the I2RS Agent by the 268 I2RS client SHOULD be done over a secure transport. It is 269 anticipated that the passing of most I2RS ephemeral state operational 270 status SHOULD be done over a secure transport. Data models SHOULD 271 clearly annotate what data nodes can be passed over an insecure 272 connection. The default transport is a secure transport. 274 SEC-REQ-10: A secure transport MUST be associated with a key 275 management solution that can guarantee that only the entities having 276 sufficient privileges can get the keys to encrypt/decrypt the 277 sensitive data. Per BCP107 [RFC4107] this key management system 278 SHOULD be automatic, but MAY BE manual if the following constraints 279 from BCP107: 281 a)environment has limited bandwidth or high round-trip times, 283 b)the information being protected has a low value and 285 c)the total volume over the entire lifetime of the long-term 286 session key will be very low, 288 d)the scale of the deployment is limited. 290 Most I2RS environments (I2RS Client - I2S Agents) will not have this 291 environment, but a few I2RS use case provide limited non-secure 292 light-weight telemetry messages that have these requirements. An 293 I2RS data model must indicate which portions can be served by manual 294 key management. 296 SEC-REQ-11: The I2RS protocol MUST be able to support multiple secure 297 transport sessions providing protocol and data communication between 298 an I2RS Agent and an I2RS client. However, a single I2RS Agent to 299 I2RS client connection MAY elect to use a single secure transport 300 session or a single non-secure transport session. 302 SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement 303 mechanisms that mitigate DoS attacks 305 2.3. Data Confidentiality Requirements 307 SEC-REQ-13: In a critical infrastructure, certain data within routing 308 elements is sensitive and read/write operations on such data MUST be 309 controlled in order to protect its confidentiality. For example, 310 most carriers do not want a router's configuration and data flow 311 statistics known by hackers or their competitors. While carriers may 312 share peering information, most carriers do not share configuration 313 and traffic statistics. To achieve this, access control to sensitive 314 data needs to be provided, and the confidentiality protection on such 315 data during transportation needs to be enforced. 317 2.4. Data Integrity Requirements 319 SEC-REQ-14: An integrity protection mechanism for I2RS SHOULD be able 320 to ensure the following: 1) the data being protected is not modified 321 without detection during its transportation and 2) the data is 322 actually from where it is expected to come from 3) the data is not 323 repeated from some earlier interaction of the protocol. That is, 324 when both confidentiality and integrity of data is properly 325 protected, it is possible to ensure that encrypted data is not 326 modified or replayed without detection. 328 SEC-REQ-15: The integrity that the message data is not repeated means 329 that I2RS client to I2RS agent transport SHOULD protect against 330 replay attack 332 Requirements SEC-REQ-13 and SEC-REQ-14 are SHOULD requirements only 333 because it is recognized that some I2RS Client to I2RS agent 334 communication occurs over a non-secure channel. The I2RS client to 335 I2RS agent over a secure channel would implement these features. In 336 order to provide some traceability or notification for the non-secure 337 protocol, SEC-REQ-16 suggests traceability and notification are 338 important to include for any non-secure protocol. 340 SEC-REQ-17: The I2RS message traceability and notification 341 requirements requirements found in [I-D.ietf-i2rs-traceability] and 342 [I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in 343 communication channel that is non-secure to trace or notify about 344 potential security issues 346 2.5. Role-Based Data Model Security 348 The [I-D.ietf-i2rs-architecture] defines a role or security role as 349 specifying read, write, or notification access by a I2RS client to 350 data within an agent's data model. 352 SEC-REQ-18: The rules around what role is permitted to access and 353 manipulate what information plus a secure transport (which protects 354 the data in transit) SHOULD ensure that data of any level of 355 sensitivity is reasonably protected from being observed by those 356 without permission to view it, so that privacy requirements are met. 358 SEC-REQ-19: Role security MUST work when multiple transport 359 connections are being used between the I2RS client and I2RS agent as 360 the I2RS architecture [I-D.ietf-i2rs-architecture] states. These 361 transport message streams may start/stop without affecting the 362 existence of the client/agent data exchange. TCP supports a single 363 stream of data. SCTP [RFC4960] provides security for multiple 364 streams plus end-to-end transport of data. 366 SEC-REQ-20: I2RS clients MAY be used by multiple applications to 367 configure routing via I2RS agents, receive status reports, turn on 368 the I2RS audit stream, or turn on I2RS traceability. Application 369 software using I2RS client functions may host several multiple secure 370 identities, but each connection will use only one identifier with one 371 priority. Therefore, the security of each I2RS Client to I2RS Agent 372 connection is unique. 374 Please note the security of the application to I2RS client connection 375 is outside of the I2RS protocol or I2RS interface. 377 3. Acknowledgement 379 The author would like to thank Wes George, Ahmed Abro, Qin Wu, Eric 380 Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia 381 Atlas, and Jeff Haas for their contributions to the I2RS security 382 requirements discussion and this document. 384 4. IANA Considerations 386 This draft includes no request to IANA. 388 5. Security Considerations 390 This is a document about security requirements for the I2RS protocol 391 and data modules. The whole document is security considerations. 393 6. References 395 6.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, 399 DOI 10.17487/RFC2119, March 1997, 400 . 402 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 403 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 404 June 2005, . 406 6.2. Informative References 408 [I-D.haas-i2rs-ephemeral-state-reqs] 409 Haas, J., "I2RS Ephemeral State Requirements", draft-haas- 410 i2rs-ephemeral-state-reqs-00 (work in progress), May 2015. 412 [I-D.ietf-i2rs-architecture] 413 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 414 Nadeau, "An Architecture for the Interface to the Routing 415 System", draft-ietf-i2rs-architecture-09 (work in 416 progress), March 2015. 418 [I-D.ietf-i2rs-problem-statement] 419 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 420 Routing System Problem Statement", draft-ietf-i2rs- 421 problem-statement-06 (work in progress), January 2015. 423 [I-D.ietf-i2rs-pub-sub-requirements] 424 Voit, E., Clemm, A., and A. Prieto, "Requirements for 425 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 426 requirements-02 (work in progress), March 2015. 428 [I-D.ietf-i2rs-rib-info-model] 429 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 430 Information Base Info Model", draft-ietf-i2rs-rib-info- 431 model-06 (work in progress), March 2015. 433 [I-D.ietf-i2rs-traceability] 434 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 435 the Routing System (I2RS) Traceability: Framework and 436 Information Model", draft-ietf-i2rs-traceability-03 (work 437 in progress), May 2015. 439 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 440 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 441 . 443 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 444 RFC 4960, DOI 10.17487/RFC4960, September 2007, 445 . 447 Authors' Addresses 449 Susan Hares 450 Huawei 451 7453 Hickory Hill 452 Saline, MI 48176 453 USA 455 Email: shares@ndzh.com 457 Daniel Migault 458 Ericsson 459 8400 boulevard Decarie 460 Montreal, QC HAP 2N2 461 Canada 463 Email: daniel.migault@ericsson.com 465 Joel Halpern 466 Ericsson 467 US 469 Email: joel.halpern@ericsson.com