idnits 2.17.1 draft-hares-i2rs-auth-trans-04.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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 3, 2015) is 3219 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: 'RFC2119' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 362, 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 (~~), 10 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: January 4, 2016 J. Halpern 6 Ericsson 7 July 3, 2015 9 I2RS Security Related Requirements 10 draft-hares-i2rs-auth-trans-04 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 January 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Security-Related Requirements . . . . . . . . . . . . . . . . 4 55 2.1. Mutual authentication of I2RS client and I2RS Agent . . . 4 56 2.2. Transport Requirements Based on Mutual Authentication . . 5 57 2.3. Data Confidentiality Requirements . . . . . . . . . . . . 5 58 2.4. Message Integrity Requirements . . . . . . . . . . . . . 5 59 2.4.1. Handling Multiple Messages . . . . . . . . . . . . . 6 60 2.5. Role-Based Data Model Security . . . . . . . . . . . . . 6 61 3. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 6.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 were initially described in the [I-D.ietf-i2rs-architecture] 81 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. Definitions 94 This document utilizes the definitions found in the following drafts: 95 [RFC4949], and [I-D.ietf-i2rs-architecture] 97 Specifically, this document utilizes the following definitions: 99 Authentication 101 [RFC4949] describes authentication as the process of verifying 102 (i.e., establishing the truth of) an attribute value claimed by or 103 for a system entity or system resource. Authentication has two 104 steps: identify and verify. 106 Data Confidentiality 108 [RFC4949] describes data confidentiality as having two properties: 109 a) data is not disclosed to system entities unless they have been 110 authorized to know, and b) data is not disclosed to unauthorized 111 individuals, entities or processes. The key point is that 112 confidentiality implies that the originator has the ability to 113 authorize where the information goes. Confidentiality is 114 important for both read and write scope of the data. 116 Data Privacy 118 [RFC4949] describes data privacy as a synonym for data 119 confidentiality. This I2RS document will utilize data privacy as 120 a synonym for data confidentiality. 122 Mutual Authentication 124 [RFC4949] implies that mutual authentication exists between two 125 interacting system entities. Mutual authentication in I2RS 126 implies that both sides move from a state of mutual suspicion to 127 mutually authenticated communication afte each system has been 128 identified and validated by its peer system. 130 Security audit trail 132 [RFC4949] (page 254) describes a security audit trail as a 133 chronological record of system activities that is sufficient to 134 enable the reconstruction and examination of the sequence 135 environments and activities surrounding or leading to an 136 operation, procedure, or event in a security-relevant transaction 137 from inception to final results. Requirements to support a 138 security audit is not covered in this document. The draft 139 [I-D.ietf-i2rs-traceability] describes traceability for I2RS 140 interface and protocol. Traceability is not equivalent to a 141 security audit trail. 143 I2RS integrity 145 The data transfer as it is transmitted between client and agent 146 cannot be modified by unauthorized parties without detection. 148 2. Security-Related Requirements 150 The security for the I2RS protocol requires mutually authenticated 151 I2RS clients and I2RS agents. The I2RS client and I2RS agent using 152 the I2RS protocol MUST be able to exchange data over a secure 153 transport, but some functions may operate on non-secure transport. 154 The I2RS protocol MUST BE able to provide atomicity of a transaction, 155 but it is not required to have multi-message atomicity and rollback 156 mechanism transactions. Multiple messages transactions may be 157 impacted by the interdependency of data. This section discusses 158 these details of these security requirements. 160 2.1. Mutual authentication of I2RS client and I2RS Agent 162 The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following 163 requirements: 165 o SEC-REQ-01: All I2RS clients and I2RS agents MUST have at least 166 one unique identifier that uniquely identifies each party. 168 o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for 169 mutual identification of the I2RS client and I2RS agent. 171 o SEC-REQ-03:An I2RS agent, upon receiving an I2RS message from a 172 client, MUST confirm that the client has a valid identity. 174 o SEC-REQ-04: The client, upon receiving an I2RS message from an 175 agent, MUST confirm the I2RS agent's identity. 177 o SEC-REQ-05: Identity distribution and the loading of these 178 identities into I2RS agent and I2RS Client SHOULD occur outside 179 the I2RS protocol. 181 o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF 182 or private) will distribute or load identities so that the I2RS 183 client/agent has these identities prior to the I2RS protocol 184 establishing a connection between I2RS client and I2RS agent. 186 o SEC-REQ-07: Each Identity MUST be linked to one priority 188 o SEC-REQ-08: Each Identity is associated with one secondary 189 identity during a particular read/write sequence, but the 190 secondary identity may vary during the time a connection between 191 the I2RS client and I2RS agent is active. The variance of the 192 secondary identity allows the I2rs client to be associated with 193 multiple applications and pass along an identifier for these 194 applications in the secondary identifier. 196 2.2. Transport Requirements Based on Mutual Authentication 198 SEC-REQ-09: The data security of the I2RS protocol MUST be able to 199 support transfer of the data over a secure transport and optionally 200 be able to support a non-security transport. A security transport is 201 defined to have the qualities of confidentiality, has message 202 integrity, prevents replay attakc, and supports end-to-end integrity 203 of the I2RS client-agent session. 205 SEC-REQ-10: A secure transport MUST be be associated with a key 206 management solution that can guarantee that only the entities having 207 sufficient privileges can get the keys to encrypt/decrypt the 208 sensitive data. Pre-shared keys is considered for this document to 209 be a key management system. In addition, the key management 210 mechanisms need to be able to update the keys before they have lost 211 sufficient security strengths, without breaking the connection 212 between the agents and clients. 214 SEC-REQ-11: The I2RS protocol MUST be able to support multiple secure 215 transport sessions providing protocol and data communication between 216 an I2RS Agent and an I2RS client. However, a single I2RS Agent to 217 I2RS client connection MAY elect to use a single secure transport 218 session or a single non-secure transport session. 220 SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement 221 mechanisms that mitigate DoS attacks 223 2.3. Data Confidentiality Requirements 225 SEC-REQ-13: In a critical infrastructure, certain data within routing 226 elements is sensitive and read/write operations on such data MUST be 227 controlled in order to protect its confidentiality. For example, 228 most carriers do not want a router's configuration and data flow 229 statistics known by hackers or their competitors. While carriers may 230 share peering information, most carriers do not share configuration 231 and traffic statistics. To achieve this, access control to sensitive 232 data needs to be provided, and the confidentiality protection on such 233 data during transportation needs to be enforced. 235 2.4. Message Integrity Requirements 237 SEC-REQ-14: An integrity protection mechanism for I2RS SHOULD be able 238 to ensure the following: 1) the data being protected is not modified 239 without detection during its transportation and 2) the data is 240 actually from where it is expected to come from 3) the data is not 241 repeated from some earlier interaction of the protocol. That is, 242 when both confidentiality and integrity of data is properly 243 protected, it is possible to ensure that encrypted data is not 244 modified or replayed without detection. 246 sec-REQ-15: The integrity that the message data is not repeated means 247 that I2RS client to I2RS agent transport SHOULD protect against 248 replay attack 250 Requirements SEC-REQ-13 and SEC-REQ-14 are SHOULD requirements only 251 because it is recognized that some I2RS Client to I2RS agent 252 communication occurs over a non-secure channel. The I2RS client to 253 I2RS agent over a secure channel would implement these features. In 254 order to provide some traceability or notification for the non-secure 255 protocol, SEC-REQ-16 suggests traceability and notification are 256 important to include for any non-secure protocol. 258 SEC-REQ-16: The I2RS message traceability and notification 259 requirements requirements found in [I-D.ietf-i2rs-traceability] and 260 [I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in 261 communication channel that is non-secure to trace or notify about 262 potential security issues 264 2.4.1. Handling Multiple Messages 266 Section 7.9 of the [I-D.ietf-i2rs-architecture] states the I2RS 267 architecture does not include multi-message atomicity and rollback 268 mechanisms, but suggests an I2RS client may indicate one of the 269 following error handling techniques for a given message sent to the 270 I2RS client: 272 1. Perform all or none: All operations succeed or none of them will 273 be applied. This useful when there are mutual dependencies. 275 2. Perform until error: Operations are applied in order, and when 276 error occurs the processing stops. This is useful when 277 dependencies exist between multiple-message operations, and order 278 is important. 280 3. Perform all storing errors: Perform all actions storing error 281 indications for errors. This method can be used when there are 282 no dependencies between operations, and the client wants to sort 283 it out. 285 2.5. Role-Based Data Model Security 287 The [I-D.ietf-i2rs-architecture] defines a role or security role as 288 specifying read, write, or notification access by a I2RS client to 289 data within an agent's data model. 291 SEC-REQ-18: The rules around what role is permitted to access and 292 manipulate what information plus a secure transport (which protects 293 the data in transit) SHOULD ensure that data of any level of 294 sensitivity is reasonably protected from being observed by those 295 without permission to view it, so that privacy requirements are met. 296 Observers without permission can refer to other I2RS clients, 297 attackers, or assorted MITM (man-in-the-middle) monkeys. 299 SEC-REQ-19: Role security MUST work when multiple transport 300 connections are being used between the I2RS client and I2RS agent as 301 the I2RS architecture [I-D.ietf-i2rs-architecture] states. These 302 transport message streams may start/stop without affecting the 303 existence of the client/agent data exchange. TCP supports a single 304 stream of data. SCTP [RFC4960] provides security for multiple 305 streams plus end-to-end transport of data. 307 SEC-REQ-20: I2RS clients MAY be used by multiple applications to 308 configure routing via I2RS agents, receive status reports, turn on 309 the I2RS audit stream, or turn on I2RS traceability. Application 310 software using I2RS client functions may host several multiple secure 311 identities, but each connection will use only one identity with one 312 priority. Therefore, the security of each I2RS Client to I2RS Agent 313 connection is unique. 315 Please note the security of the application to I2RS client connection 316 is outside of the I2RS protocol or I2RS interface. 318 3. Acknowledgement 320 The author would like to thank Wes George, Ahmed Abro, Qin Wu, Eric 321 Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia 322 Atlas, and Jeff Haas for their contributions to the I2RS security 323 requirements discussion and this document. 325 4. IANA Considerations 327 This draft includes no request to IANA. 329 5. Security Considerations 331 This is a document about security requirements for the I2RS protocol 332 and data modules. The whole document is security considerations. 334 6. References 335 6.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 6.2. Informative References 342 [I-D.haas-i2rs-ephemeral-state-reqs] 343 Haas, J., "I2RS Ephemeral State Requirements", draft-haas- 344 i2rs-ephemeral-state-reqs-00 (work in progress), May 2015. 346 [I-D.ietf-i2rs-architecture] 347 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 348 Nadeau, "An Architecture for the Interface to the Routing 349 System", draft-ietf-i2rs-architecture-09 (work in 350 progress), March 2015. 352 [I-D.ietf-i2rs-problem-statement] 353 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 354 Routing System Problem Statement", draft-ietf-i2rs- 355 problem-statement-06 (work in progress), January 2015. 357 [I-D.ietf-i2rs-pub-sub-requirements] 358 Voit, E., Clemm, A., and A. Prieto, "Requirements for 359 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 360 requirements-02 (work in progress), March 2015. 362 [I-D.ietf-i2rs-rib-info-model] 363 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 364 Information Base Info Model", draft-ietf-i2rs-rib-info- 365 model-06 (work in progress), March 2015. 367 [I-D.ietf-i2rs-traceability] 368 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 369 the Routing System (I2RS) Traceability: Framework and 370 Information Model", draft-ietf-i2rs-traceability-03 (work 371 in progress), May 2015. 373 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 374 4949, August 2007. 376 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 377 4960, September 2007. 379 Authors' Addresses 381 Susan Hares 382 Huawei 383 7453 Hickory Hill 384 Saline, MI 48176 385 USA 387 Email: shares@ndzh.com 389 Daniel Migault 390 Ericsson 391 8400 boulevard Decarie 392 Montreal, QC HAP 2N2 393 Canada 395 Email: daniel.migault@ericsson.com 397 Joel Halpern 398 Ericsson 399 US 401 Email: joel.halpern@ericsson.com