idnits 2.17.00 (12 Aug 2021) /tmp/idnits28802/draft-hares-i2rs-security-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 == Line 209 has weird spacing: '...dentity v ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 6, 2015) is 2654 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: 'Constraints' is mentioned on line 212, but not defined == Unused Reference: 'I-D.clarke-i2rs-traceability' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'I-D.hares-i2rs-info-model-policy' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'I-D.ji-i2rs-usecases-ccne-service' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'I-D.keyupate-i2rs-bgp-usecases' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'I-D.white-i2rs-use-case' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'RFC4785' is defined on line 473, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-clarke-i2rs-traceability-02 == Outdated reference: draft-ietf-i2rs-architecture has been published as RFC 7921 == Outdated reference: draft-ietf-i2rs-problem-statement has been published as RFC 7920 == Outdated reference: draft-ietf-i2rs-rib-info-model has been published as RFC 8430 Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). 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 S. Brim 5 Expires: August 10, 2015 Consultant 6 N. Cam-Winget 7 Cisco 8 J. Halpern 9 Ericcson 10 D. Zhang 11 Q. Wu 12 Huawei 13 A. Abro 14 S. Asadullah 15 Cisco 16 J. Halpern 17 Ericcson 18 E. Yu 19 Cisco 20 February 6, 2015 22 I2RS Security Considerations 23 draft-hares-i2rs-security-03 25 Abstract 27 This presents an expansion of the security architecture found in the 28 i2rs architecture. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 10, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Security Issues . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Security roles and Identities for the I2RS client and I2RS 68 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. I2RS Data Security . . . . . . . . . . . . . . . . . . . . . 7 70 5.1. Data Confidentiality Requirements . . . . . . . . . . . . 8 71 5.2. Message Integrity Requirements . . . . . . . . . . . . . 8 72 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 10. Informative References . . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 The Interface to the Routing System (I2RS) provides read and write 82 access to the information and state within the routing process and 83 configuration process (as illustrated in the diagram in the 84 architecture document within routing elements. The I2RS client 85 [I-D.ietf-i2rs-architecture] interacts with one or more I2RS agents 86 to collect information from network routing systems. This security 87 architecture expands on the security issues involved in the I2RS 88 protocol's message exchange between the I2RS client and the I2RS 89 agent which are described in [I-D.ietf-i2rs-architecture] 91 2. Definitions 93 This document utilizes the definitions found in the following drafts: 94 [RFC4949], and [I-D.ietf-i2rs-architecture] 96 Specifically, this document utilizes the following definitions: 98 Authentication 100 [RFC4949] describes authentication as the process of verifying 101 (i.e., establishing the truth of) an attribute value claimed by or 102 for a system entity or system resource. Authentication has two 103 steps: identify and verify. 105 Data Confidentiality 107 [RFC4949] describes data confidentiality as having two properties: 108 a) data is not disclosed to system entities unless they have been 109 authorized to know, and b) data is not disclosed to unauthorized 110 individuals, entities or processes. The key point is that 111 confidentiality implies that the originator has the ability to 112 authorize where the information goes. Confidentiality is 113 important for both read and write scope of the data. 115 Data confidentiality service 117 [RFC4949] also describes data confidentiality service as a 118 security service that protects data against unauthorized 119 disclosure. Please note that an operator can designate all people 120 are authorized to view a piece of data which would mean a data 121 confidentiality service would be essentially a null function. 123 Data Privacy 125 [RFC4949] describes data privacy as a synonym for data 126 confidentiality. This I2RS document will utilize data privacy as 127 a synonym for data confidentiality. 129 Mutual Authentication 131 [RFC4949] implies that mutual authentication exists between two 132 interacting system entities. Mutual authentication in I2RS 133 implies that both sides move from a state of mutual suspicion to 134 mutually authenticated communication afte each system has been 135 identified and validated by its peer system 137 Mutual Suspicion 139 [RFC4949] defines mutual suspicion as a state that exists between 140 two interacting system entities in which neither entity can trust 141 the other to function correctly with regard to some security 142 requirement. 144 Role 146 [RFC4949] describes role as a job function or employment position 147 to which people or other system entities may be assigned in a 148 system. In the I2RS interface, the I2RS agent roles relate to the 149 roles that the I2RS client is utilizing. In the I2RS interface, 150 the I2RS client negotiation is over the client's ability to access 151 resources made available through the agent's particular role. 153 Role-based Access control 155 [RFC4949] describes role-based access control as an identity-based 156 access control wherein the system entities that are identified and 157 controlled are functional positions in an organization or process. 158 Within [RFC4949] five relationships are discussed: 1) 159 administrators to assign identities to roles, 2) administrators to 160 assign permissions to roles, 3) administrators to assign roles to 161 roles, 4) users to select identities in sessions, and 5) users to 162 select roles in sessions. This document discusses I2RS use of 163 Roles as Scope+Access where scope is the portion of the routing 164 tree, and access is permissions to read or write (or both). 165 Figure 1 replicates [RFC4949] diagram on RBAC roles and 166 assignments (page 254). 168 Role hierarchy or Permissions inheritance 170 [RFC4949] describes the hierarchy of roles and identities in role- 171 based access control shown in Figure 1 and described above. I2RS 172 will used role-based access control as defined above, and shown in 173 Figure 2. 175 Role certificate 177 [RFC4949] describes a role certificate as an organizational 178 certificate that is issued to a system entity that is a member of 179 the set of users that have identities that are assigned to the 180 same role. 182 Security audit trail 184 [RFC4949] (page 254) describes a security audit trail as a 185 chronological record of system activities that is sufficient to 186 enable the reconstruction and examination of the sequence 187 environments and activities surrounding or leading to an 188 operation, procedure, or event in a security-relevant transaction 189 from inception to final results. To apply this to the I2RS 190 system, this implies that the processes on the I2RS client-I2RS 191 Agent protocol and related actions on the I2RS-Agent can record a 192 set of activity that will allow the reconstruction and examination 193 of the sequence of environments and activities around actions 194 caused by the I2RS protocol data streams. 196 I2RS integrity 198 The data transfer as it is transmitted between client and agent 199 cannot be modified by unauthorized parties without detection. 201 The following diagram is a variation of the [RFC4949] diagram on 202 role-based security, and provides the context for the assumptions of 203 security on the role-based work. 205 (c) Permission Inheritance Assignments (i.e., Role Hierarchy) 206 [Constraints] 207 +=====+ 208 | | 209 (a) Identity v v (b) Permission 210 +----------+ Assignments +-------+ Assignments +----------+ 211 |Identities|<=============>| Roles |<=============>|Permissions| 212 +----------+ [Constraints] +-------+ [Constraints] +----------+ 213 | | ^ ^ 214 | | +-----------+ | | +---------------------+ 215 | | | +-------+ | | | | Legend | 216 | +====>|Session|=====+ | | | 217 | | +-------+ | | | One-to-One | 218 | | ... | | | =================== | 219 | | +-------+ | | | | 220 +========>|Session|=========+ | One-to-Many | 221 (d) Identity | +-------+ | (e) Role | ==================> | 222 Selections | | Selections | | 223 [Constraints]| Access |[Constraints] | Many-to-Many | 224 | Sessions | | <================> | 225 +-----------+ +---------------------+ 227 Figure 1 - Security definition of Role inheritance 229 3. Security Issues 231 The security for the I2RS protocol utilizes the role based access 232 security for the I2RS client's access to the I2RS agent's data (read/ 233 write). The I2RS [I-D.ietf-i2rs-architecture] treats the agent's 234 notification stream or publication stream as a pre-authorized read. 235 This security consideration document examines the major points: 237 I2RS roles and identities 239 This section looks at how I2RS roles and identities created by 240 [I-D.ietf-i2rs-architecture], how I2RS model derived from the 241 security model of role-based access control matches the 242 [I-D.ietf-i2rs-architecture], and how Identities and roles get 243 distributed. 245 Data Security 247 The data security section looks at incidents when the I2RS data 248 stream will need confidentiality and message integrity, transport 249 security, how role-based access control of I2RS data impacts the 250 I2RS Information Model and Data Model design, and light weight 251 clients who work without confidentiality. 253 4. Security roles and Identities for the I2RS client and I2RS Agent 255 All I2RS clients and I2RS agents MUST have at least one unique 256 identifier that uniquely identifies each party. The I2RS protocol 257 MUST utilize these identifiers for mutual identification of the 258 client and agent. An I2RS agent, upon receiving an I2RS message from 259 a client, must confirm that the client has a valid identity. The 260 client, upon receiving an I2RS message from an agent, must confirm 261 the I2RS identity. 263 Identity distribution and the loading of these identities into I2RS 264 agent and I2RS Client occur outside the I2RS protocol. The I2RS 265 protocol SHOULD assume some mechanism (IETF or private) in order to 266 distribute or load identities and that the I2RS client/agent will 267 load the identities prior to the I2RS protocol establishing a 268 connection between I2RS client and I2RS agent. 270 Each Identity will be linked (via internal policy) to one role. The 271 context of the I2RS client-agent communication is based on a role 272 which may/may not require message confidentiality, message integrity 273 protection, or replay attack protection. 275 The rigorous definition of a role in RBAC-based security is role is 276 function associated with an activity (set of actions). The set of 277 actions in I2RS performs is limited are read or write actions on a 278 specific set of data in the data model. Therefore, we can express: 280 Role = routing tree + Read/Write/Read-Write 282 Role security for an agent involves pairing the identity to the role. 283 The data store can read information either by write or an event 284 stream. 286 Role security exists even if multiple transport connections are being 287 used between the I2RS client and I2RS agent as the I2RS architecture 288 [I-D.ietf-i2rs-architecture] states. These transport message streams 289 may start/stop without affecting the existence of the client/agent 290 data exchange. TCP supports a single stream of data. SCTP [RFC4960] 291 provides security for multiple streams plus end-to-end transport of 292 data. 294 I2RS clients may be used by multiple applications to configure 295 routing via I2RS agents, receive status reports, turn on the I2RS 296 audit stream, or turn on I2RS traceability. An I2RS client software 297 could arrange to store multiple secure identities, and use a specific 298 identity that only associates roles which only have Read access. 299 This administrative design of identities and roles could insure a 300 "status-only" application did gain write access. This administrative 301 design is possible within I2RS architecture but not mandated. 303 Multiple identities provide some secondary level support for the 304 application-client, but may grow the number of identities. The 305 multiple identities per client could also be used for multiple levels 306 of security for the data passed between an I2RS client and agent as 307 either: a) confidential, b) authorized with message integrity 308 protection, c) authorized without message integrity protection, and 309 or d) no protection. 311 5. I2RS Data Security 313 I2RS data security involves determining of the I2RS client to I2RS 314 agent data transfer needs to be confidential, or have message 315 integrity, or support an end-to-end integrity (in the case of stacked 316 clients). This section discuss the consideration of I2RS data 317 security. 319 It is assumed that all I2RS data security mechanisms used for 320 protecting the I2RS packets needs to be associated with proper key 321 management solutions. A key management solution needs to guarantee 322 that only the entities having sufficient privileges can get the keys 323 to encrypt/decrypt the sensitive data. In addition, the key 324 management mechanisms need to be able to update the keys before they 325 have lost sufficient security strengths, without breaking the 326 connection between the agents and clients. 328 The rules around what role is permitted to access and manipulate what 329 information, combined with encryption to protect the data in transit 330 is intended to help ensure that data of any level of sensitivity is 331 reasonably protected from being observed by those without permission 332 to view it. In that case 'those' can refer to either other roles, 333 sub-agents, or to attackers and assorted MITM monkeys. 335 5.1. Data Confidentiality Requirements 337 In a critical infrastructure, certain data within routing elements is 338 sensitive and R/W operations on such data must be controlled in order 339 to protect its confidentiality. For example, most carriers do not 340 want a router's configuration and data flow statistics known by 341 hackers or their competitors. While carriers may share peering 342 information, most carriers do not share configuration and traffic 343 statistics. To achieve this, access control to sensitive data needs 344 to be provided, and the confidentiality protection on such data 345 during transportation needs to be enforced. 347 It is normal to protect the confidentiality of the sensitive data 348 during transportation by encrypting them. Encryption obscures the 349 data transported on the wire and protects them against eavesdropping 350 attacks. Because the encryption itself cannot guarantee the 351 integrity or fresh of data being transported, in practice, 352 confidentiality protection is normally provided with integrity 353 protection. 355 5.2. Message Integrity Requirements 357 An integrity protection mechanism for I2RS should be able to ensure 358 1) the data being protected are not modified without detection during 359 its transportation and 2) the data is actually from where it is 360 expected t come from 3) the data is not repeated from some earlier 361 interaction of the protocol. That is, when both confidentiality and 362 integrity of data is properly protected, it is possible to ensure 363 that encrypted data are not modified or replayed without detection. 365 As a part of integrity protection, the replay protection approaches 366 provided for I2RS must consider both online and offline attackers, 367 and have sufficient capability to deal with intra connection and 368 inter-connection attacks. For instance, when using symmetric keys, 369 sequence numbers which increase monotonically could be useful to help 370 in distinguishing the replayed messages, under the assistance of 371 signatures or MACs (dependent on what types of keys are applied). In 372 addition, in the cases where only offline attacker is considered, 373 random nonce could be effective. 375 6. Open Issues 377 The following are open issues for the I2RS WG to discuss: 379 Unencrypted Message Exchanges 381 The I2RS Security discussion group believes that encrypting all 382 the data messages is the best approach for security. Some I2RS WG 383 discussion has indicated a desire for the the I2RS client-agent 384 message exchanges to be unencrypted. The discussion group needs 385 the I2RS WG members to provide more detail since a mixture of 386 encrypted and unencrypted data will require more complexity in the 387 Information Model (IM) and Data Model (DM). 389 Transport requirements 391 The architecture provides the ability to have multiple transport 392 sessions providing protocol and data communication between the 393 I2RS Agent and the I2RS client. The discussion group proposed on 394 mandatory secure transport. Should there be one mandatory secure 395 transport protocol or multiple allowable protocols? 397 Auditable Data Streams 399 Auditable data streams does not have a security consideration 400 because I2RS is not inventing a new audit protocol as many 401 protocols (syslog) are available to be used. Verifying audit 402 stream data is outside the I2RS protocol, but those designing the 403 IM and DMs with audit stream capability need to provide the 404 appropriate hooks such as: on/off action, data selection, and 405 protocol (for example syslog) that the I2RS Agent (or I2RS routing 406 system) sends the audit data upon. 408 7. Acknowledgement 410 The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric 411 Yu, Alia Atlas, and Jeff Haas for their wonderful contributions to 412 our discussion discussion. 414 8. IANA Considerations 416 This draft includes no request to IANA. 418 9. Security Considerations 420 This is a document about security architecture beyond the 421 consideration for I2RS. Additional security definitions will be 422 added in this section. 424 10. Informative References 426 [I-D.clarke-i2rs-traceability] 427 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 428 the Routing System (I2RS) Traceability: Framework and 429 Information Model", draft-clarke-i2rs-traceability-02 430 (work in progress), June 2014. 432 [I-D.hares-i2rs-info-model-policy] 433 Hares, S. and W. Wu, "An Information Model for Basic 434 Network Policy", draft-hares-i2rs-info-model-policy-03 435 (work in progress), July 2014. 437 [I-D.ietf-i2rs-architecture] 438 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 439 Nadeau, "An Architecture for the Interface to the Routing 440 System", draft-ietf-i2rs-architecture-08 (work in 441 progress), January 2015. 443 [I-D.ietf-i2rs-problem-statement] 444 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 445 Routing System Problem Statement", draft-ietf-i2rs- 446 problem-statement-06 (work in progress), January 2015. 448 [I-D.ietf-i2rs-rib-info-model] 449 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 450 Information Base Info Model", draft-ietf-i2rs-rib-info- 451 model-05 (work in progress), January 2015. 453 [I-D.ji-i2rs-usecases-ccne-service] 454 Ji, X., Zhuang, S., Huang, T., and S. Hares, "I2RS Use 455 Cases for Control of Forwarding Path by Central Control 456 Network Element (CCNE)", draft-ji-i2rs-usecases-ccne- 457 service-02 (work in progress), July 2014. 459 [I-D.keyupate-i2rs-bgp-usecases] 460 Patel, K., Fernando, R., Gredler, H., Amante, S., White, 461 R., and S. Hares, "Use Cases for an Interface to BGP 462 Protocol", draft-keyupate-i2rs-bgp-usecases-04 (work in 463 progress), July 2014. 465 [I-D.white-i2rs-use-case] 466 White, R., Hares, S., and A. Retana, "Protocol Independent 467 Use Cases for an Interface to the Routing System", draft- 468 white-i2rs-use-case-06 (work in progress), July 2014. 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 474 Ciphersuites with NULL Encryption for Transport Layer 475 Security (TLS)", RFC 4785, January 2007. 477 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 478 4949, August 2007. 480 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 481 4960, September 2007. 483 Authors' Addresses 485 Susan Hares 486 Huawei 487 7453 Hickory Hill 488 Saline, MI 48176 489 USA 491 Email: shares@ndzh.com 493 Scott Brim 494 Consultant 496 Email: scott.brim@gmail.com 498 Nancy Cam-Winget 499 Cisco 501 Email: ncamwing@cisco.com 503 Joel Halpern 504 Ericcson 506 Email: joel.halpern@ericsson.com 508 DaCheng Zhang 509 Huawei 511 Email: zhangdacheng@huawei.com 512 Qin Wu 513 Huawei 515 Email: bill.wu@huawei.com 517 Ahmed Abro 518 Cisco 520 Email: aabro@cisco.com 522 Salman Asadullah 523 Cisco 525 Email: sasad@cisco.com 527 Joel Halpern 528 Ericcson 530 Email: joel.halpern@ericsson.com 532 Eric Yu 533 Cisco 535 Email: eyu@cisco.com