idnits 2.17.1 draft-hares-i2rs-auth-trans-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 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 (June 24, 2015) is 3227 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 375, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC4785' is defined on line 411, 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 (~~), 11 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 June 24, 2015 5 Expires: December 26, 2015 7 I2RS Security Related Requirements 8 draft-hares-i2rs-auth-trans-03 10 Abstract 12 This presents an security-related requirements for the I2RS protocol 13 for mutual authentication, transport protocols, data transfer and 14 transactions. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 26, 2015. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. 10 I2RS General Requirements . . . . . . . . . . . . . . 3 52 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Security-Related Requirements . . . . . . . . . . . . . . . . 5 54 2.1. Mutual authentication of I2RS client and I2RS Agent . . . 5 55 2.2. Transport Requirements Based on Mutual Authentication . . 6 56 2.3. Data Confidentiality Requirements . . . . . . . . . . . . 6 57 2.4. Message Integrity Requirements . . . . . . . . . . . . . 7 58 2.4.1. Handling Multiple Messages . . . . . . . . . . . . . 7 59 2.5. Role-Based Data Model Security . . . . . . . . . . . . . 7 60 3. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 6.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 The Interface to the Routing System (I2RS) provides read and write 71 access to the information and state within the routing process. The 72 I2RS client interacts with one or more I2RS agents to collect 73 information from network routing systems. 75 This document describes the requirements for the I2RS protocol in the 76 security-related areas of mutual authentication of the I2RS client 77 and agent, the transport protocol carrying the I2RS protocol 78 messages, and the atomicity of the transactions. These requirements 79 were initially described in the [I-D.ietf-i2rs-architecture] 80 document. These security requirements are also part of the list of 81 top ten requirements for the I2RS protocol indicated in the section 82 below. 84 [I-D.haas-i2rs-ephemeral-state-reqs] discusses of I2RS roles-based 85 write conflict resolution in the ephemeral data store using the I2RS 86 Client Identity, I2RS Secondary Identity and priority. The draft 87 [I-D.ietf-i2rs-traceability] describes the traceability framework and 88 its requirements for I2RS. The draft 89 [I-D.ietf-i2rs-pub-sub-requirements] describe the requirements for 90 I2RS to be able to publish information or have a remote client 91 subscribe to an information data stream. 93 1.1. 10 I2RS General Requirements 95 1. The I2RS protocol SHOULD support highly reliable notifications 96 (but not perfectly reliable notifications) from an I2RS agent to 97 an I2RS client. 99 2. The I2RS protocol SHOULD support a high bandwidth, asynchronous 100 interface, with real-time guarantees on getting data from an 101 I2RS agent by an I2RS client. 103 3. The I2RS protocol will operate on data models which may be 104 protocol independent or protocol dependent. 106 4. I2RS Agent needs to record the client identity when a node is 107 created or modified. The I2RS Agent needs to be able to read 108 the client identity of a node and use the client identity's 109 associated priority to resolve conflicts. The secondary 110 identity is useful for traceability and may also be recorded. 112 5. Client identity will have only one priority for the client 113 identity. A collision on writes is considered an error, but 114 priority is utilized to compare requests from two different 115 clients in order to modify an existing node entry. Only an 116 entry from a client which is higher priority can modify an 117 existing entry (First entry wins). Priority only has meaning at 118 the time of use. 120 6. The Agent identity and the Client identity should be passed 121 outside of the I2RS protocol in a authentication and 122 authorization protocol (AAA). Client priority may be passed in 123 the AAA protocol. The values of identities are originally set 124 by operators, and not standardized. 126 7. An I2RS Client and I2RS Agent mutually authenticate each other 127 based on pre-established authenticated identities. 129 8. Secondary identity data is read-only meta-data that is recorded 130 by the I2RS agent which associated with a data model's node when 131 the node is written, updated or deleted. Just like the primary 132 identity, the secondary identity is only recorded when the data 133 node is written or updated or deleted. 135 9. I2RS agent can have a lower priority I2RS client attempting to 136 modify a higher priority client's entry in a data model. The 137 filtering out of lower priority clients attempting to write or 138 modify a higher priority client's entry in a data model SHOULD 139 be effectively handled and not put an undue strain on the I2RS 140 agent. Note: Jeff's suggests that priority is kept at the NACM 141 at the client level (rather than the path level or the group 142 level) will allow these lower priority clients to be filtered 143 out using an extended NACM approach. This is only a suggestion 144 of a method to provide the requirement 146 10. The I2RS protocol MUST support the use of a secure transport. 147 However, certain functions such as notifications MAY use a non- 148 secure transport. Each model or service (notification, logging) 149 must define within the model or service the valid uses of a non- 150 secure transport. 152 1.2. Definitions 154 This document utilizes the definitions found in the following drafts: 155 [RFC4949], and [I-D.ietf-i2rs-architecture] 157 Specifically, this document utilizes the following definitions: 159 Authentication 161 [RFC4949] describes authentication as the process of verifying 162 (i.e., establishing the truth of) an attribute value claimed by or 163 for a system entity or system resource. Authentication has two 164 steps: identify and verify. 166 Data Confidentiality 168 [RFC4949] describes data confidentiality as having two properties: 169 a) data is not disclosed to system entities unless they have been 170 authorized to know, and b) data is not disclosed to unauthorized 171 individuals, entities or processes. The key point is that 172 confidentiality implies that the originator has the ability to 173 authorize where the information goes. Confidentiality is 174 important for both read and write scope of the data. 176 Data Privacy 178 [RFC4949] describes data privacy as a synonym for data 179 confidentiality. This I2RS document will utilize data privacy as 180 a synonym for data confidentiality. 182 Mutual Authentication 184 [RFC4949] implies that mutual authentication exists between two 185 interacting system entities. Mutual authentication in I2RS 186 implies that both sides move from a state of mutual suspicion to 187 mutually authenticated communication afte each system has been 188 identified and validated by its peer system. 190 Security audit trail 192 [RFC4949] (page 254) describes a security audit trail as a 193 chronological record of system activities that is sufficient to 194 enable the reconstruction and examination of the sequence 195 environments and activities surrounding or leading to an 196 operation, procedure, or event in a security-relevant transaction 197 from inception to final results. Requirements to support a 198 security audit is not covered in this document. The draft 199 [I-D.ietf-i2rs-traceability] describes traceability for I2RS 200 interface and protocol. Traceability is not equivalent to a 201 security audit trail. 203 I2RS integrity 205 The data transfer as it is transmitted between client and agent 206 cannot be modified by unauthorized parties without detection. 208 2. Security-Related Requirements 210 The security for the I2RS protocol requires mutually authenticated 211 I2RS client and I2RS agent. The I2RS client and I2RS agent using the 212 I2RS protocol MUST be able to exchange data over a secure transport, 213 but some functions may operate on non-secure transport. The I2RS 214 protocol MUST BE able to provide atomicity of a transaction, but it 215 is not required to multi-message atomicity and rollback mechanisms 216 transactions. Multiple messages transactions may be impacted by the 217 interdependency of data. This section discusses these details of 218 these securitry requirements. 220 2.1. Mutual authentication of I2RS client and I2RS Agent 222 The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following 223 requirements: 225 o All I2RS clients and I2RS agents MUST have at least one unique 226 identifier that uniquely identifies each party. 228 o The I2RS protocol MUST utilize these identifiers for mutual 229 identification of the I2RS client and I2RS agent. 231 o An I2RS agent, upon receiving an I2RS message from a client, MUST 232 confirm that the client has a valid identity. 234 o The client, upon receiving an I2RS message from an agent, MUST 235 confirm the I2RS identity. 237 o Identity distribution and the loading of these identities into 238 I2RS agent and I2RS Client occur outside the I2RS protocol. 240 o The I2RS protocol SHOULD assume some mechanism (IETF or private) 241 will distribute or load identities so that the I2RS client/agent 242 has these identities prior to the I2RS protocol establishing a 243 connection between I2RS client and I2RS agent. 245 o Each Identity will be linked to one priority 247 o Each Identity is associated with one secondary identity during a 248 particular read/write sequence, but the secondary identity may 249 vary during the time a connection between the I2RS client and I2RS 250 agent is active. The variance of the secondary identity allows 251 the I2rs client to be associated with multiple applications and 252 pass along an identifier for these applications in the secondary 253 identifier. 255 2.2. Transport Requirements Based on Mutual Authentication 257 The data security of the I2RS protocol MUST be able to support 258 transfer of the data over a secure transport and optionally be able 259 to support a non-security transport. A security transport is defined 260 to have the qualities of confidentiality, has message integrity, and 261 supports end-to-end integrity of the I2RS client-agent session. 263 A secure transport also must be be associated with a key management 264 solution that can guarantee that only the entities having sufficient 265 privileges can get the keys to encrypt/decrypt the sensitive data. 266 Pre-shared keys is considered for this document to be a key 267 management system. In addition, the key management mechanisms need 268 to be able to update the keys before they have lost sufficient 269 security strengths, without breaking the connection between the 270 agents and clients. 272 The I2RS protocol MUST be able to support multiple secure transport 273 sessions providing protocol and data communication between an I2RS 274 Agent and an I2RS client. However, a single I2RS Agent to I2RS 275 client connect MAY elect to use a single secure transport session or 276 a single non-secure transport session. 278 2.3. Data Confidentiality Requirements 280 In a critical infrastructure, certain data within routing elements is 281 sensitive and read/write operations on such data must be controlled 282 in order to protect its confidentiality. For example, most carriers 283 do not want a router's configuration and data flow statistics known 284 by hackers or their competitors. While carriers may share peering 285 information, most carriers do not share configuration and traffic 286 statistics. To achieve this, access control to sensitive data needs 287 to be provided for this data, and the confidentiality protection on 288 such data during transportation needs to be enforced. 290 2.4. Message Integrity Requirements 292 An integrity protection mechanism for I2RS should be able to ensure 293 the following: 1) the data being protected are not modified without 294 detection during its transportation and 2) the data is actually from 295 where it is expected to come from 3) the data is not repeated from 296 some earlier interaction of the protocol. That is, when both 297 confidentiality and integrity of data is properly protected, it is 298 possible to ensure that encrypted data are not modified or replayed 299 without detection. 301 2.4.1. Handling Multiple Messages 303 Section 7.9 of the [I-D.ietf-i2rs-architecture] states the I2RS 304 architecture does not include multi-message atomicity and rollback 305 mechanisms, but suggests an I2RS client may inidicate one of the 306 following error handling techniques for a given message sent to the 307 I2RS client: 309 1. Perform all or none: All operations succeed or none of them will 310 be applied. This useful when there are mutual dependencies. 312 2. Perform until error: Operations are applied in order, and when 313 error occurs the processing stops. This is useful when 314 dependencies exist between multiple-message operations, and order 315 is important. 317 3. Perform all storing errors: Perform all actions storing error 318 indications for errors. This method can be used when there are 319 no dependencies between operations, and the client wants to sort 320 it out. 322 2.5. Role-Based Data Model Security 324 The [I-D.ietf-i2rs-architecture] defines a role or security role as 325 specifying read, write, or notification access within a data model 326 that a client has to an agent's data model. 328 The rules around what role is permitted to access and manipulate what 329 information plus a secure transport (which protects the data in 330 transit) SHOULD ensure that data of any level of sensitivity is 331 reasonably protected from being observed by those without permission 332 to view it so that privacy requirements are met. Observer without 333 permission can refer to other I2RS clients, attackers, or assorted 334 MITM (man-in-the-middle) monkeys. 336 Role security MUST work when multiple transport connections are being 337 used between the I2RS client and I2RS agent as the I2RS architecture 338 [I-D.ietf-i2rs-architecture] states. These transport message streams 339 may start/stop without affecting the existence of the client/agent 340 data exchange. TCP supports a single stream of data. SCTP [RFC4960] 341 provides security for multiple streams plus end-to-end transport of 342 data. 344 I2RS clients MAY be used by multiple applications to configure 345 routing via I2RS agents, receive status reports, turn on the I2RS 346 audit stream, or turn on I2RS traceability. An application software 347 using I2RS client functions can host several multiple secure 348 identities, but each connection will use only one identity with one 349 priority. Therefore, the security of each I2RS Client to I2RS Agent 350 connection is unique. 352 Please note the security of the application to I2RS client connection 353 is outside of the I2RS protocol or I2RS interface. 355 3. Acknowledgement 357 The author would like to thank Wes George, Ahmed Abro, Qin Wu, Eric 358 Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia 359 Atlas, and Jeff Haas for their contributions to I2RS security 360 requirement discussion and this document. 362 4. IANA Considerations 364 This draft includes no request to IANA. 366 5. Security Considerations 368 This is a document about security requirements for the I2RS protocol 369 and data modules. The whole document is security considerations. 371 6. References 373 6.1. Normative References 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, March 1997. 378 6.2. Informative References 380 [I-D.haas-i2rs-ephemeral-state-reqs] 381 Haas, J., "I2RS Ephemeral State Requirements", draft-haas- 382 i2rs-ephemeral-state-reqs-00 (work in progress), May 2015. 384 [I-D.ietf-i2rs-architecture] 385 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 386 Nadeau, "An Architecture for the Interface to the Routing 387 System", draft-ietf-i2rs-architecture-09 (work in 388 progress), March 2015. 390 [I-D.ietf-i2rs-problem-statement] 391 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 392 Routing System Problem Statement", draft-ietf-i2rs- 393 problem-statement-06 (work in progress), January 2015. 395 [I-D.ietf-i2rs-pub-sub-requirements] 396 Voit, E., Clemm, A., and A. Prieto, "Requirements for 397 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 398 requirements-02 (work in progress), March 2015. 400 [I-D.ietf-i2rs-rib-info-model] 401 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 402 Information Base Info Model", draft-ietf-i2rs-rib-info- 403 model-06 (work in progress), March 2015. 405 [I-D.ietf-i2rs-traceability] 406 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 407 the Routing System (I2RS) Traceability: Framework and 408 Information Model", draft-ietf-i2rs-traceability-03 (work 409 in progress), May 2015. 411 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 412 Ciphersuites with NULL Encryption for Transport Layer 413 Security (TLS)", RFC 4785, January 2007. 415 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 416 4949, August 2007. 418 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 419 4960, September 2007. 421 Author's Address 422 Susan Hares 423 Huawei 424 7453 Hickory Hill 425 Saline, MI 48176 426 USA 428 Email: shares@ndzh.com