idnits 2.17.1 draft-hares-i2rs-auth-trans-01.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 23, 2015) is 3224 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 371, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'RFC4785' is defined on line 407, 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 23, 2015 5 Expires: December 25, 2015 7 I2RS Security Related Requirements 8 draft-hares-i2rs-auth-trans-01 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 25, 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 . . . . . . . . . . . . 7 57 2.4. Message Integrity Requirements . . . . . . . . . . . . . 7 58 2.4.1. Handling Multiple Messages . . . . . . . . . . . . . 7 59 2.5. Role-Based Data Model Security . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 8 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]document states: 224 "Mutual authentication between the I2RS Client and I2RS Agent is 225 required. An I2RS Client must be able to trust that the I2RS 226 Agent is attached to the relevant Routing Element so that write/ 227 modify operations are correctly applied and so that information 228 received from the I2RS Agent can be trusted by the I2RS Client." 230 This architecture set the following requirements: 232 o All I2RS clients and I2RS agents MUST have at least one unique 233 identifier that uniquely identifies each party. 235 o The I2RS protocol MUST utilize these identifiers for mutual 236 identification of the I2RS client and I2RS agent. 238 o An I2RS agent, upon receiving an I2RS message from a client, MUST 239 confirm that the client has a valid identity. 241 o The client, upon receiving an I2RS message from an agent, MUST 242 confirm the I2RS identity. 244 o Identity distribution and the loading of these identities into 245 I2RS agent and I2RS Client occur outside the I2RS protocol. 247 o The I2RS protocol SHOULD assume some mechanism (IETF or private) 248 will distribute or load identities so that the I2RS client/agent 249 has these identities prior to the I2RS protocol establishing a 250 connection between I2RS client and I2RS agent. 252 o Each Identity will be linked to one priority 254 o Each Identity is associated with one secondary identity during a 255 particular read/write sequence, but the secondary identity may 256 vary during the time a connection between the I2RS client and I2RS 257 agent is active. The variance of the secondary identity allows 258 the I2rs client to be associated with multiple applications and 259 pass along an identifier for these applications in the secondary 260 identifier. 262 2.2. Transport Requirements Based on Mutual Authentication 264 The data security of the I2RS protocol MUST be able to support 265 transfer of the data over a secure transport and optionally be able 266 to support a non-security transport. A security transport is defined 267 to have the qualities of: confidentiality, has message integrity, and 268 supports end-to-end integrity (in the case of stacked clients). 270 A secure transport also must be be associated with a key management 271 solution that can guarantee that only the entities having sufficient 272 privileges can get the keys to encrypt/decrypt the sensitive data. 273 Pre-shared keys is considered for this document to be a key 274 management system. In addition, the key management mechanisms need 275 to be able to update the keys before they have lost sufficient 276 security strengths, without breaking the connection between the 277 agents and clients. 279 The rules around what role is permitted to access and manipulate what 280 information combined a secure transport protect the data in transit 281 SHOULD ensure that data of any level of sensitivity is reasonably 282 protected from being observed by those without permission to view it 283 so that privacy requirements are met. Observer without permission 284 can refer to other I2RS clients, attackers, or assorted MITM (man-in- 285 the-middle)monkeys. 287 The I2RS protocol MUST support multiple secure transport sessions 288 providing protocol and data communication between the I2RS Agent and 289 the I2RS client. 291 2.3. Data Confidentiality Requirements 293 In a critical infrastructure, certain data within routing elements is 294 sensitive and read/write operations on such data must be controlled 295 in order to protect its confidentiality. For example, most carriers 296 do not want a router's configuration and data flow statistics known 297 by hackers or their competitors. While carriers may share peering 298 information, most carriers do not share configuration and traffic 299 statistics. To achieve this, access control to sensitive data needs 300 to be provided for this data, and the confidentiality protection on 301 such data during transportation needs to be enforced. 303 2.4. Message Integrity Requirements 305 An integrity protection mechanism for I2RS should be able to ensure 306 1) the data being protected are not modified without detection during 307 its transportation and 2) the data is actually from where it is 308 expected to come from 3) the data is not repeated from some earlier 309 interaction of the protocol. That is, when both confidentiality and 310 integrity of data is properly protected, it is possible to ensure 311 that encrypted data are not modified or replayed without detection. 313 2.4.1. Handling Multiple Messages 315 >Section 7.9 of the [I-D.ietf-i2rs-architecture] states the I2RS 316 architecture does not include multi-message atomicity and rollback 317 mechanisms, but suggests an I2RS client may inidicate one of the 318 following error handling techniques for a given message sent to the 319 I2RS client: 321 1. Perform all or none: All operations succeed or none of them will 322 be applied. This useful when there are mutual dependencies. 324 2. Perform until error: Operations are applied in order, and when 325 error occurs the processing stops. This is useful when 326 dependencies exist between multiple-message operations, and order 327 is important. 329 3. Perform all storing errors: Perform all actions storing error 330 indications for errors. This method can be used when there are 331 no dependencies between operations, and the client wants to sort 332 it out. 334 2.5. Role-Based Data Model Security 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 connection is unique.. 351 3. Acknowledgement 353 The author would like to thank Wes George, Ahmed Abro, Qin Wu, Eric 354 Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia 355 Atlas, and Jeff Haas for their contributions to I2RS security 356 requirement discussion and this document. 358 4. IANA Considerations 360 This draft includes no request to IANA. 362 5. Security Considerations 364 This is a document about security requirements for the I2RS protocol 365 and data modules. The whole document is security considerations. 367 6. References 369 6.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, March 1997. 374 6.2. Informative References 376 [I-D.haas-i2rs-ephemeral-state-reqs] 377 Haas, J., "I2RS Ephemeral State Requirements", draft-haas- 378 i2rs-ephemeral-state-reqs-00 (work in progress), May 2015. 380 [I-D.ietf-i2rs-architecture] 381 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 382 Nadeau, "An Architecture for the Interface to the Routing 383 System", draft-ietf-i2rs-architecture-09 (work in 384 progress), March 2015. 386 [I-D.ietf-i2rs-problem-statement] 387 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 388 Routing System Problem Statement", draft-ietf-i2rs- 389 problem-statement-06 (work in progress), January 2015. 391 [I-D.ietf-i2rs-pub-sub-requirements] 392 Voit, E., Clemm, A., and A. Prieto, "Requirements for 393 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 394 requirements-02 (work in progress), March 2015. 396 [I-D.ietf-i2rs-rib-info-model] 397 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 398 Information Base Info Model", draft-ietf-i2rs-rib-info- 399 model-06 (work in progress), March 2015. 401 [I-D.ietf-i2rs-traceability] 402 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 403 the Routing System (I2RS) Traceability: Framework and 404 Information Model", draft-ietf-i2rs-traceability-03 (work 405 in progress), May 2015. 407 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 408 Ciphersuites with NULL Encryption for Transport Layer 409 Security (TLS)", RFC 4785, January 2007. 411 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 412 4949, August 2007. 414 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 415 4960, September 2007. 417 Author's Address 419 Susan Hares 420 Huawei 421 7453 Hickory Hill 422 Saline, MI 48176 423 USA 425 Email: shares@ndzh.com