idnits 2.17.1 draft-hares-i2rs-auth-trans-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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 10, 2015) is 3235 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: 'RFC6242' is mentioned on line 322, but not defined == Unused Reference: 'RFC2119' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC4785' is defined on line 492, 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 (~~), 12 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 10, 2015 5 Expires: December 12, 2015 7 I2RS Security Related Requirements 8 draft-hares-i2rs-auth-trans-00 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 12, 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 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Security-Related Requirements . . . . . . . . . . . . . . . . 6 54 3.1. Mutual authentication of I2RS client and I2RS Agent . . . 6 55 3.2. Transport Requirements Based on Mutual Authentication . . 7 56 3.2.1. NETCONF over SSH . . . . . . . . . . . . . . . . . . 7 57 3.2.2. NETCONF/RESTCONF over TLS . . . . . . . . . . . . . . 8 58 3.3. Data Confidentiality Requirements . . . . . . . . . . . . 8 59 3.4. Message Integrity Requirements . . . . . . . . . . . . . 8 60 3.5. Role-Based Data Model Security . . . . . . . . . . . . . 9 61 4. Data Transaction Requirements . . . . . . . . . . . . . . . . 9 62 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 67 8.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 The Interface to the Routing System (I2RS) provides read and write 73 access to the information and state within the routing process. The 74 I2RS client interacts with one or more I2RS agents to collect 75 information from network routing systems. 77 This document describes the requirements for the I2RS protocol in the 78 security-related areas of mutual authentication of the I2RS client 79 and agent, the transport protocol carrying the I2RS protocol 80 messages, and the atomicity of the transactions. These requirements 81 were initially described in the [I-D.ietf-i2rs-architecture] 82 document. These security requirements are also part of the list of 83 top ten requirements for the I2RS protocol indicated in the section 84 below. 86 [I-D.haas-i2rs-ephemeral-state-reqs] discusses of I2RS roles-based 87 write conflict resolution in the ephemeral data store using the I2RS 88 Client Identity, I2RS Secondary Identity and priority. The draft 89 [I-D.ietf-i2rs-traceability] describes the traceability framework and 90 its requirements for I2RS. The draft 91 [I-D.ietf-i2rs-pub-sub-requirements] describe the requirements for 92 I2RS to be able to publish information or have a remote client 93 subscribe to an information data stream. 95 1.1. 10 I2RS General Requirements 97 o 1. The I2RS protocol SHOULD support highly reliable notifications 98 (but not perfectly reliable notifications) from an I2RS agent to 99 an I2RS client. 101 o 2. The I2RS protocol SHOULD support a high bandwidth, 102 asynchronous interface, with real-time guarantees on getting data 103 from an I2RS agent by an I2RS client. 105 o 3. The I2RS protocol will operate on data models which may be 106 protocol independent or protocol dependent. 108 o 4. I2RS Agent needs to record the client identity when a node is 109 created or modified. The I2RS Agent needs to be able to read the 110 client identity of a node and use the client identity's associated 111 priority to resolve conflicts. The secondary identity is useful 112 for traceability and may also be recorded. 114 o 5. Client identity will have only one priority for the client 115 identity. A collision on writes is considered an error, but 116 priority is utilized to compare requests from two different 117 clients in order to modify an existing node entry. Only an entry 118 from a client which is higher priority can modify an existing 119 entry (First entry wins). Priority only has meaning at the time 120 of use. 122 o 6. The Agent identity and the Client identity should be passed 123 outside of the I2RS protocol in a authentication and authorization 124 protocol (AAA). Client priority may be passed in the AAA 125 protocol. The values of identities are originally set by 126 operators, and not standardized. 128 o 7.An I2RS Client and I2RS Agent mutually authenticate each other 129 based on pre-established authenticated identities. 131 o 8. Secondary identity data is read-only meta-data that is 132 recorded by the I2RS agent associated with a data model's node is 133 written, updated or deleted. Just like the primary identity, the 134 secondary identity is only recorded when the data node is written 135 or updated or deleted. 137 o 9.I2RS agent can have a lower priority I2RS client attempting to 138 modify a higher priority client's entry in a data model. The 139 filtering out of lower priority clients attempting to write or 140 modify a higher priority client's entry in a data model SHOULD be 141 effectively handled and not put an undue strain on the I2RS agent. 142 Note: Jeff's suggests that priority is kept at the NACM at the 143 client level (rather than the path level or the group level) will 144 allow these lower priority clients to be filtered out using an 145 extended NACM approach. This is only a suggestion of a method to 146 provide the requirement 148 o 10. The I2RS protocol MUST support the use of a secure transport. 149 However, certain functions such as notifications MAY use a non- 150 secure transport. Each model or service (notification, logging) 151 must define within the model or service the valid uses of a non- 152 secure transport. 154 2. Definitions 156 This document utilizes the definitions found in the following drafts: 157 [RFC4949], and [I-D.ietf-i2rs-architecture] 159 Specifically, this document utilizes the following definitions: 161 Authentication 163 [RFC4949] describes authentication as the process of verifying 164 (i.e., establishing the truth of) an attribute value claimed by or 165 for a system entity or system resource. Authentication has two 166 steps: identify and verify. 168 Data Confidentiality 170 [RFC4949] describes data confidentiality as having two properties: 171 a) data is not disclosed to system entities unless they have been 172 authorized to know, and b) data is not disclosed to unauthorized 173 individuals, entities or processes. The key point is that 174 confidentiality implies that the originator has the ability to 175 authorize where the information goes. Confidentiality is 176 important for both read and write scope of the data. 178 Data confidentiality service 180 [RFC4949] also describes data confidentiality service as a 181 security service that protects data against unauthorized 182 disclosure. Please note that an operator can designate all people 183 are authorized to view a piece of data which would mean a data 184 confidentiality service would be essentially a null function. 186 Data Privacy 188 [RFC4949] describes data privacy as a synonym for data 189 confidentiality. This I2RS document will utilize data privacy as 190 a synonym for data confidentiality. 192 Mutual Authentication 194 [RFC4949] implies that mutual authentication exists between two 195 interacting system entities. Mutual authentication in I2RS 196 implies that both sides move from a state of mutual suspicion to 197 mutually authenticated communication afte each system has been 198 identified and validated by its peer system 200 Mutual Suspicion 202 [RFC4949] defines mutual suspicion as a state that exists between 203 two interacting system entities in which neither entity can trust 204 the other to function correctly with regard to some security 205 requirement. 207 Role 209 [RFC4949] describes role as a job function or employment position 210 to which people or other system entities may be assigned in a 211 system. In the I2RS interface, the I2RS agent roles relate to the 212 roles that the I2RS client is utilizing. In the I2RS interface, 213 the I2RS client negotiation is over the client's ability to access 214 resources made available through the agent's particular role. 216 Role-based Access control 218 [RFC4949] describes role-based access control as an identity-based 219 access control wherein the system entities that are identified and 220 controlled are functional positions in an organization or process. 221 Within [RFC4949] five relationships are discussed: 1) 222 administrators to assign identities to roles, 2) administrators to 223 assign permissions to roles, 3) administrators to assign roles to 224 roles, 4) users to select identities in sessions, and 5) users to 225 select roles in sessions. 227 Security audit trail 229 [RFC4949] (page 254) describes a security audit trail as a 230 chronological record of system activities that is sufficient to 231 enable the reconstruction and examination of the sequence 232 environments and activities surrounding or leading to an 233 operation, procedure, or event in a security-relevant transaction 234 from inception to final results. Requirements to support a 235 security audit is not covered in this document. The draft 236 [I-D.ietf-i2rs-traceability] describes traceability for I2RS 237 interface and protocol. 239 I2RS integrity 240 The data transfer as it is transmitted between client and agent 241 cannot be modified by unauthorized parties without detection. 243 3. Security-Related Requirements 245 The security for the I2RS protocol requires mutually authenticated 246 I2RS client and I2RS agent MUST be able to exchange data over a 247 secure transport, and MUST use role-based security to store data in 248 I2RS data models in ephemeral state, and MUST provide atomicity of a 249 transaction. This section describes the requirements for the mutual 250 authentication of the I2RS agent and client, and the secure 251 transport. The issues relating to role-based security to store data 252 in I2RS data models in ephemeral state is covered in 253 [I-D.haas-i2rs-ephemeral-state-reqs]. 255 3.1. Mutual authentication of I2RS client and I2RS Agent 257 The I2RS architecture [I-D.ietf-i2rs-architecture]document states: 259 "Mutual authentication between the I2RS Client and I2RS Agent is 260 required. An I2RS Client must be able to trust that the I2RS 261 Agent is attached to the relevant Routing Element so that write/ 262 modify operations are correctly applied and so that information 263 received from the I2RS Agent can be trusted by the I2RS Client." 265 This architecture set the following requirements: 267 o All I2RS clients and I2RS agents MUST have at least one unique 268 identifier that uniquely identifies each party. 270 o The I2RS protocol MUST utilize these identifiers for mutual 271 identification of the I2RS client and I2RS agent. 273 o An I2RS agent, upon receiving an I2RS message from a client, must 274 confirm that the client has a valid identity. 276 o The client, upon receiving an I2RS message from an agent, must 277 confirm the I2RS identity. 279 o Identity distribution and the loading of these identities into 280 I2RS agent and I2RS Client occur outside the I2RS protocol. 282 o The I2RS protocol SHOULD assume some mechanism (IETF or private) 283 in order to distribute or load identities and that the I2RS 284 client/agent will load the identities prior to the I2RS protocol 285 establishing a connection between I2RS client and I2RS agent. 287 o Each Identity will be linked to one priority 288 o Each Identity will be linked to one secondary identity for the 289 period of a connection. 291 3.2. Transport Requirements Based on Mutual Authentication 293 I2RS data security MUST be able to support transfer of the data 294 between the I2RS client to I2RS agent in a manner that is 295 confidential, has message integrity, and supports end-to-end 296 integrity (in the case of stacked clients). 298 The I2RS data security mechanisms used for protecting the I2RS 299 packets needs to be associated with proper key management solutions. 300 A key management solution needs to guarantee that only the entities 301 having sufficient privileges can get the keys to encrypt/decrypt the 302 sensitive data. In addition, the key management mechanisms need to 303 be able to update the keys before they have lost sufficient security 304 strengths, without breaking the connection between the agents and 305 clients. 307 The rules around what role is permitted to access and manipulate what 308 information, combined with encryption to protect the data in transit 309 is intended SHOULD ensure that data of any level of sensitivity is 310 reasonably protected from being observed by those without permission 311 to view it. In that case 'those' can refer to either other roles, 312 sub-agents, or to attackers and assorted MITM (man-in-the- 313 middle)monkeys. 315 The I2RS protocol MUST support multiple transport sessions providing 316 protocol and data communication between the I2RS Agent and the I2RS 317 client. 319 3.2.1. NETCONF over SSH 321 The NETCONF service over SSH is believed to provide the necessary 322 mutual authentication services required by I2RS. Per [RFC6242]: "The 323 identity of the SSH server MUST be verified and authenticated by the 324 SSH client according to local policy before password-based 325 authentication data or any configuration or state data is sent to or 326 received from the SSH server. The identity of the SSH client MUST 327 also be verified and authenticated by the SSH server according to 328 local policy to ensure that the incoming SSH client request is 329 legitimate before any configuration or state data is sent to or 330 received from the SSH client. Neither side should establish a 331 NETCONF over SSH connection with an unknown, unexpected, or incorrect 332 identity on the opposite side. 334 3.2.2. NETCONF/RESTCONF over TLS 336 Agent validation of the I2RS client is mandated over TLS in an I2RS 337 context. The client shall also validate the Agent using its server 338 certificate. 340 3.3. Data Confidentiality Requirements 342 In a critical infrastructure, certain data within routing elements is 343 sensitive and read/write operations on such data must be controlled 344 in order to protect its confidentiality. For example, most carriers 345 do not want a router's configuration and data flow statistics known 346 by hackers or their competitors. While carriers may share peering 347 information, most carriers do not share configuration and traffic 348 statistics. To achieve this, access control to sensitive data needs 349 to be provided, and the confidentiality protection on such data 350 during transportation needs to be enforced. 352 It is normal to protect the confidentiality of the sensitive data 353 during transportation by encrypting them. Encryption obscures the 354 data transported on the wire and protects them against eavesdropping 355 attacks. Because the encryption itself cannot guarantee the 356 integrity or fresh of data being transported, in practice, 357 confidentiality protection is normally provided with integrity 358 protection. 360 3.4. Message Integrity Requirements 362 An integrity protection mechanism for I2RS should be able to ensure 363 1) the data being protected are not modified without detection during 364 its transportation and 2) the data is actually from where it is 365 expected to come from 3) the data is not repeated from some earlier 366 interaction of the protocol. That is, when both confidentiality and 367 integrity of data is properly protected, it is possible to ensure 368 that encrypted data are not modified or replayed without detection. 370 As a part of integrity protection, the replay protection approaches 371 provided for I2RS must consider both online and offline attackers, 372 and have sufficient capability to deal with intra connection and 373 inter-connection attacks. For instance, when using symmetric keys, 374 sequence numbers which increase monotonically could be useful to help 375 in distinguishing the replayed messages, under the assistance of 376 signatures or MACs (dependent on what types of keys are applied). In 377 addition, in the cases where only offline attacker is considered, 378 random nonce could be effective. 380 3.5. Role-Based Data Model Security 382 The context of the I2RS client-agent communication may utilize a role 383 which may/may not require message confidentiality, message integrity 384 protection, or replay attack protection. However, the I2RS Protocol 385 MUST be able to support message confidentiality, message integrity 386 protection, and replay attack protection. 388 Role security for an agent involves pairing the identity to the role. 389 The data store can read information either by write or an event 390 stream. 392 Role security MUST work when multiple transport connections are being 393 used between the I2RS client and I2RS agent as the I2RS architecture 394 [I-D.ietf-i2rs-architecture] states. These transport message streams 395 may start/stop without affecting the existence of the client/agent 396 data exchange. TCP supports a single stream of data. SCTP [RFC4960] 397 provides security for multiple streams plus end-to-end transport of 398 data. 400 I2RS clients may be used by multiple applications to configure 401 routing via I2RS agents, receive status reports, turn on the I2RS 402 audit stream, or turn on I2RS traceability. An application software 403 using I2RS client functions can host several multiple secure 404 identities, but each connection will use only one identity with one 405 priority.. Therefore, the security of each connection is unique. 407 4. Data Transaction Requirements 409 Each transaction should be treated as atomic and providing full 410 functionality. If the configuration change is not functionally 411 complete, then the transaction should fail and be rolled back 412 (rollback 0). Example, I2RS agents wants to configure BGP: 414 routing-options { 415 autonomous-system autonomous-system; 416 } 417 protocols { 418 bgp { 419 group group-name { 420 peer-as autonomous-system; 421 type type; 422 neighbor address; 423 } 424 } 425 } 427 If a statement like neighbor address is missing or is mis-formatted, 428 like 300.127.5.23, configuration is not functional, transaction 429 should fail and rollback 0 should be performed by the I2RS agent on 430 the ephemeral config store. If the neighbor address is in the 431 transaction, but the address is not reachable or similar, transaction 432 is accepted, but notification will be sent that BGP peering cannot be 433 established. 435 5. Acknowledgement 437 The author would like to thank Wes George, Ahmed Abro, Qin Wu, Eric 438 Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia 439 Atlas, and Jeff Haas for their contributions to I2RS security 440 requirement discussion, and this document. 442 6. IANA Considerations 444 This draft includes no request to IANA. 446 7. Security Considerations 448 This is a document about security architecture beyond the 449 consideration for I2RS. Additional security definitions will be 450 added in this section. 452 8. References 454 8.1. Normative References 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 8.2. Informative References 461 [I-D.haas-i2rs-ephemeral-state-reqs] 462 Haas, J., "I2RS Ephemeral State Requirements", draft-haas- 463 i2rs-ephemeral-state-reqs-00 (work in progress), May 2015. 465 [I-D.ietf-i2rs-architecture] 466 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 467 Nadeau, "An Architecture for the Interface to the Routing 468 System", draft-ietf-i2rs-architecture-09 (work in 469 progress), March 2015. 471 [I-D.ietf-i2rs-problem-statement] 472 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 473 Routing System Problem Statement", draft-ietf-i2rs- 474 problem-statement-06 (work in progress), January 2015. 476 [I-D.ietf-i2rs-pub-sub-requirements] 477 Voit, E., Clemm, A., and A. Prieto, "Requirements for 478 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 479 requirements-02 (work in progress), March 2015. 481 [I-D.ietf-i2rs-rib-info-model] 482 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 483 Information Base Info Model", draft-ietf-i2rs-rib-info- 484 model-06 (work in progress), March 2015. 486 [I-D.ietf-i2rs-traceability] 487 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 488 the Routing System (I2RS) Traceability: Framework and 489 Information Model", draft-ietf-i2rs-traceability-03 (work 490 in progress), May 2015. 492 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 493 Ciphersuites with NULL Encryption for Transport Layer 494 Security (TLS)", RFC 4785, January 2007. 496 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 497 4949, August 2007. 499 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 500 4960, September 2007. 502 Author's Address 504 Susan Hares 505 Huawei 506 7453 Hickory Hill 507 Saline, MI 48176 508 USA 510 Email: shares@ndzh.com