idnits 2.17.1 draft-lin-sacm-nid-mp-security-baseline-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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 31 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 243 has weird spacing: '...en-mode iden...' == Line 257 has weird spacing: '...en-mode iden...' == Line 259 has weird spacing: '...er-port inet...' == Line 285 has weird spacing: '...crement uin...' == Line 320 has weird spacing: '...min-len uint...' == (18 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2017) is 2363 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) == Outdated reference: A later version (-01) exists of draft-birkholz-sacm-yang-content-00 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-04 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-03 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-04 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-14 == Outdated reference: A later version (-32) exists of draft-ietf-netmod-syslog-model-17 == Outdated reference: A later version (-03) exists of draft-xia-sacm-nid-dp-security-baseline-00 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Automation and Continuous Monitoring (SACM) Q. Lin 3 Internet-Draft L. Xia 4 Intended status: Standards Track Huawei 5 Expires: May 3, 2018 October 30, 2017 7 The Data Model of Network Infrastructure Device Management Plane 8 Security Baseline 9 draft-lin-sacm-nid-mp-security-baseline-01 11 Abstract 13 Network infrastructure devices such as routers and switches are 14 important parts for network security. This document describes 15 security baseline for network infrastructure device management plane, 16 with YANG output, to provide a minimum set of important security 17 management features. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 3, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Data Model Structure . . . . . . . . . . . . . . . . . . . . 4 58 5.1. User Authentication . . . . . . . . . . . . . . . . . . . 5 59 5.1.1. User Login Security . . . . . . . . . . . . . . . . . 5 60 5.1.2. AAA User Authentication . . . . . . . . . . . . . . . 8 61 5.1.3. User Profile . . . . . . . . . . . . . . . . . . . . 9 62 5.2. System Management Security . . . . . . . . . . . . . . . 10 63 5.2.1. SNMP Management Security . . . . . . . . . . . . . . 10 64 5.2.2. NETCONF Management Security . . . . . . . . . . . . . 13 65 5.3. Log Security . . . . . . . . . . . . . . . . . . . . . . 14 66 5.4. File Security . . . . . . . . . . . . . . . . . . . . . . 15 67 6. Network Infrastructure Device Security Baseline Yang Module . 16 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 73 10.2. Informative References . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 76 1. Introduction 78 Securing network infrastructure devices is a challenging and critical 79 task for organizations and operators to preserve confidentiality, 80 integrity and availability for network and network traffic 81 information. Thus, development and deployment of security baseline 82 for network infrastructure is needed to provide a solid foundation 83 for the overall network security. 85 To address threats and attacks to network infrastructure devices, 86 different security functions are implemented in application layer, 87 network layer and infrastructure layer. Network layer of network 88 infrastructure device is typically categorized into three planes of 89 operation: management plane, control plane and data plane. All the 90 planes should be protected and monitored to secure network. 92 This document focuses on security baseline for network infrastructure 93 device management plane. Management plane provides configuration and 94 monitoring services to network infrastructure devices. It provides a 95 platform for all the system management traffic. Unauthorized access, 96 insecure access channels, insecure cryptographic algorithms are 97 common security issues that break management plane security. To 98 enhance security, secure configuration should be implemented to 99 ensure proper configuration and control of network infrastructure 100 devices. A number of security best practices have been proposed, 101 such as disabling unused services and ports, discarding insecure 102 access channels, enforcing strong user authentication and 103 authorization, etc. In this document, we propose the most important 104 and universal points of management plane security baseline to provide 105 a minimum set. Thus, future extensibility can be achieved. 107 [I-D.birkholz-sacm-yang-content] defines a method of constructing the 108 YANG data model scheme for the security posture assessment of the 109 network infrastructure device by brokering of YANG push telemetry via 110 SACM statements. In this document, we follow the same way to define 111 the YANG output for network infrastructure device security posture 112 based on the [I-D.ietf-sacm-information-model]. 114 Besides management plane security baseline, the security baselines 115 for control plane, data plane, application layer and infrastructure 116 layer of network infrastructure devices are described in 117 [I-D.dong-sacm-nid-cp-security-baseline], 118 [I-D.xia-sacm-nid-dp-security-baseline] and [I-D.xia-sacm-nid-app- 119 infr-layers-security-baseline] respectively. 121 2. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. Terminology 129 This document uses the terms defined in YANG - A Data Modeling 130 Language for the Network Configuration Protocol (NETCONF) [RFC6020]. 132 4. Tree Diagrams 134 A simplified graphical representation of the data model is used in 135 this document. The meaning of the symbols in these diagrams is as 136 follows: 138 o Brackets "[" and "]" enclose list keys. 140 o Abbreviations before data node names: "rw" means configuration 141 (read-write) and "ro" state data (read-only). 143 o Symbols after data node names: "?" means an optional node, "!" 144 means a presence container, and "*" denotes a "list" and "leaf- 145 list". 147 o Parentheses enclose choice and case nodes, and case nodes are also 148 marked with a colon (":"). 150 o Ellipsis ("...") stands for contents of subtrees that are not 151 shown. 153 5. Data Model Structure 155 The following parts describe several key points of management plane 156 security baseline, including user authentication, system management 157 security, log security and file security. Both security 158 configuration and runtime state of security controls are taken into 159 consideration. 161 The overall structure is: 163 module:network-device-security 164 +--rw user-authentication 165 | +--rw user-login-security [I-D.ietf-netconf-tls-client-server] 166 | [I-D.ietf-netconf-ssh-client-server] 167 | +--rw aaa-user-authentication [RFC7317] 168 | +--rw user-profile [RFC7317] 169 +--rw system-management-security 170 | +--rw snmp-security [RFC7407] 171 | +--rw netconf-security [RFC7317] 172 | [I-D.ietf-netconf-netconf-client-server] 173 +--log-security [I-D.ietf-netmod-syslog-model] 174 +--rw file-security 176 There exists a multitude of YANG models for network devices and 177 network protocols. For management plane security, several RFCs and 178 drafts has defined related parts. These RFCs and drafts are listed 179 in the above structure. But an overall data model of management 180 plane security is still missing. Moreover, the related data models 181 may only focus on part of the security functions. The following 182 sections will reuse the existing YANG models and provide additional 183 modules or groupings for the missing parts. 185 Draft [I-D.ietf-netconf-tls-client-server] and draft 186 [I-D.ietf-netconf-ssh-client-server] focus on YANG models for TLS- 187 specific configuration and SSH-specific configuration respectively. 188 The transport-level configuration, such as what ports to listen-on or 189 connect-to, is not included. Draft 191 [I-D.ietf-netconf-netconf-client-server] defines NETCONF YANG model 192 based on the data models defined in the above two documents. 194 [RFC7317] defines a YANG data model for system management of device 195 containing a NETCONF sever. It summarizes data modules for NETCONF 196 user authentication, and RADIUS server configuration. Three methods 197 are defined for user authentication: public key for local users over 198 SSH, password for local users over any secure transport, password for 199 RADIUS users over any secure transport. 201 [RFC7407] defines a YANG model for SNMP configuration, including 202 community-based security module for SNMPv1 and SNMPv2c, as well as 203 view-based access control module and user-based security module for 204 SNMPv3. 206 Draft [I-D.ietf-netmod-syslog-model] defines a YANG model for Syslog 207 configuration, including TLS based transport security and syslog 208 messages signing. 210 5.1. User Authentication 212 The "user-authentication" module is divided into three parts: 214 module:user-authentication 215 +--rw user-authentication 216 +--rw user-login-security [I-D.ietf-netconf-tls-client-server] 217 | [I-D.ietf-netconf-ssh-client-server] 218 +--rw aaa-user-authentication [RFC7317] 219 +--rw user-profile [RFC7317] 221 5.1.1. User Login Security 223 Network infrastructure devices typically can be managed through 224 command line or web user interface. To configure a device through 225 command line, a user can log in to a device through the console port 226 or using remote access channel. Generally, there are two types of 227 user interfaces for CLI configuration: console user interface and 228 virtual type terminal (VTY) user interface. When a device functions 229 as a server, a user can use the web user interface for login and 230 configuration. The web user interface provides basic maintenance and 231 management functions. Sometimes a user still needs to use the CLI to 232 implement complex or fine-grained management. If insecure access 233 channels have to be used, several security controls should be 234 enforced. Access Control List (ACL) can be used to enforce security 235 policies on vty login and web login. In this document, "ietf-access- 236 control-list" module defined in [I-D.ietf-netmod-acl-model] is reused 237 for access control of remote login. 239 submodule:user-login-security 240 +--rw user-login-security 241 +--rw (user-interface-type) 242 +--:(console) 243 | +--rw console-user-authen-mode identityref 244 | +--rw console-user-level uint8 245 +--:(vty) 246 | +--rw absolute-number uint8 247 | +--rw relative-number uint8 248 | +--rw vty-user-authen-mode identityref 249 | +--rw vty-user-level uint8 250 | +--rw ip-block-params {ip-block-enable}? 251 | +--rw acl*? [acl-name acl-type] 252 | | +--rw acl-name string 253 | | +--rw acl-type acl:acl-type 254 | +--:(remote-channel) 255 | +--:(telnet) 256 | | +--rw telnet-enable boolean 257 | | +--rw telent-authen-mode identityref 258 | | +--rw telnet-server-source unint16 259 | | +--rw telent-server-port inet:port-number 260 | | +--rw telent-timeout uint16 261 | +--:(ssh) 262 | +--rw ssh-enable boolean 263 | +--rw ssh-security-params 264 +--:(web) 265 +--rw web-authen-mode identityref 266 +--rw web-user-level uint8 267 +--rw telnet-server-source unint16 268 +--rw https-ipv4-enable boolean 269 +--rw https-ipv6-enable boolean 270 +--rw https-source-port inet:port-number 271 +--rw https-timeout uint16 272 +--rw acl*? [acl-name acl-type] 273 | +--rw acl-name string 274 | +--rw acl-type acl:acl-type 275 +--rw tls-security-params 277 The structure of "ip-block-params" is: 279 grouping: ip-block-params 280 +--rw ip-block-params 281 | +--rw (ip-block-type) 282 | +--:(ip-block-at-first-fail) 283 | | +--rw ip-block-initial-time uint8 284 | | +--rw ip-max-fail-times? uint8 285 | | +--rw ip-block-time-increment uint8 286 | | +--rw ip-block-increment-ratio? boolean 287 | +--:(ip-block-at-several-fails) 288 | +--rw ip-fail-times uint8 289 | +--rw ip-fail-period uint8 290 | +--rw ip-block-time uint16 291 +--ro blocked-list* [blocked-ip] 292 +--ro blocked-ip inet:host 293 +--ro unblocked-interval uint16 295 The structure of "ssh-security-params" is: 297 grouping: ssh-security-params 298 +--rw ssh-security-params 299 +--rw ssh-service-type identityref 300 +--rw ssh-authen-mode identityref 301 +--rw ssh-server-port? inet:port-number 302 +--rw ssh-timeout? uint8 303 +--rw ssh-retry-times uint8 304 +--rw ssh-server-source uint16 305 +--rw host-keys 306 | +--rw host-key* [name] 307 | +--rw name string 308 | +--rw (host-key-type) 309 | +--:(public-key) -> /ks:keystore/keys/key/name 310 | +--:(certificate) 311 | +--rw certificate? leafref {sshcom:ssh-x509-certs}? 312 +--rw client-cert-auth {sshcom:ssh-x509-certs}? 313 | +--rw trusted-ca-certs? leafref 314 | +--rw trusted-client-certs? leafref 315 +--rw transport-params {ssh-server-transport-params-config}? 316 +--rw host-key 317 | +--rw host-key-alg* identityref 318 +--rw key-exchange 319 | +--rw key-exchange-alg* identityref 320 | +--rw dh-exchange-min-len uint8 321 +--rw encryption 322 | +--rw encryption-alg* identityref 323 +--rw mac 324 | +--rw mac-alg* identityref 325 +--rw compression 326 +--rw compression-alg* identityref 328 The above structure reuses "ssh-server-grouping" defined in 329 [I-D.ietf-netconf-ssh-client-server]. And it also adds other 330 security configurations, such as authentication mode and SSH server 331 port number. 333 The structure of "tls-security-params" is: 335 grouping: tls-security-params 336 +--rw tls-security-params 337 +--rw certificates 338 | +--rw certificate* [name] 339 | +--rw name? leafref 340 +--rw client-auth 341 | +--rw pinned-ca-certs? -> /ks:keystore/pinned-certificates/name 342 | +--rw pinned-client-certs? -> /ks:keystore/pinned-certificates/nam 343 +--rw hello-params {tls-server-hello-params-config}? 344 +--rw tls-versions 345 | +--rw tls-version* identityref 346 +--rw cipher-suites 347 +--rw cipher-suite* identityref 349 The above structure import the grouping defined in 350 [I-D.ietf-netconf-tls-client-server]. 352 5.1.2. AAA User Authentication 354 Authentication, Authorization, and Accounting (AAA) provides user 355 management for network devices. RADIUS (Remote Authentication Dial 356 In User Service) and TACACS (Terminal Access Controller Access 357 Control System) are the commonly used AAA mechanisms. [RFC7317] 358 defines RADIUS client model for NETCONF. This section reuses the 359 definition and add "radius-server-type" to distinguish the two 360 different server types: authentication and authorization server, 361 accounting server. Besides, TACACS data model is also provided. 363 submodule: aaa-user-authentication 364 +--rw aaa-user-authentication 365 +--rw (aaa-mode) 366 +--:(radius) 367 | +--rw radius-server* [name] 368 | +--rw name string 369 | +--rw (transport) 370 | | +--:(udp) 371 | | +--rw address inet:host 372 | | +--rw authentication-port? inet:port-number 373 | | +--rw shared-secret string 374 | +--rw authentication-type? identityref 375 | +--rw radius-server-type identityref 376 +--:(tacacs) 377 +--rw tacacs-server* [name] 378 +--rw name string 379 +--rw (transport) 380 | +--:(tcp) 381 | +--rw address inet:host 382 | +--rw authentication-port? inet:port-number 383 | +--rw shared-secret string 384 +--rw authentication-type? identityref 385 +--rw tacacs-server-type identityref 387 5.1.3. User Profile 389 User profiles are defined for user access control. For password 390 based authentication, the complexity of user password should be 391 confirmed. 393 submodule: user-profile 394 +--rw user-profile 395 +--rw user* [user-name] 396 +--rw user-name string 397 +--rw password ianach:crypt-hash 398 +--rw password-policy-params? 399 +--rw user-privilege-level uint8 400 +--rw user-service-type identityref 401 +--rw authorized-key* [name] 402 +--rw name string 403 +--rw algorithm identityref 404 +--rw pulic-key binary 406 The above structure reuses user authentication model defined in 407 [RFC7317] for NETCONF users. To support user authentication in 408 different user interfaces, additional parameters are added. 410 The structure of "password-policy-params" is: 412 grouping: password-policy-params 413 +--rw password-policy? 414 +--rw min-username-length uint8 415 +--rw min-password-length uint8 416 +--rw password-character? 417 | +--rw password-character-type enumeration 418 | +--rw password-character-min-type uint8 419 +--rw compare-past-password? 420 | +--rw past-times uint8 421 +--rw compare-username? boolean 423 5.2. System Management Security 425 The "system-management-security" module is divided into two parts: 427 module: system-management-security 428 +--rw system-management-security 429 +--rw snmp-security [RFC7407] 430 +--rw netconf-security [RFC7317] 431 [I-D.ietf-netconf-netconf-client-server] 433 5.2.1. SNMP Management Security 435 Simple Network Management Protocol (SNMP) is a network management 436 standard for monitoring managed network devices. Three SNMP versions 437 are available: SNMPv1, SNMPv2c, and SNMPv3. [RFC7407] defines 438 community-based security model for SNMPv1 and SNMPv2c, view-based 439 access control model and user-based security model for SNMPv3. The 440 following module reuses the security control related submodules 441 defined in RFC7407 for SNMP security configuration, substitutes SSH 442 and TLS common parameters grouping with the groupings defined in 443 section Section 5.1.1. 445 submodule:snmp-management-security 446 +--rw snmp-management-security 447 +--rw target* [name] 448 | +--rw name snmp:identifier 449 | +--rw (transport) 450 | | +--:(udp) 451 | | | +--rw udp 452 | | | +--rw ip inet:ip-address 453 | | | +--rw port? inet:port-number 454 | | | +--rw prefix-length? uint8 455 | | +--:(tls) 456 | | | +--rw tls 457 | | | +--rw tls-security-params 458 | | +--:(dtls) 459 | | | +--rw dtls 460 | | | +--rw tls-security-params 461 | | +--:(ssh) 462 | | +--rw ssh 463 | | +--rw ssh-security-params 464 | +--rw tlstm 465 | | +--rw cert-to-name* [id] 466 | | +--rw id uint32 467 | | +--rw fingerprint x509c2n:tls-fingerprint 468 | | +--rw map-type identityref 469 | | +--rw name string 470 | +--rw tag* snmp:identifier 471 | +--rw timeout? uint32 472 | +--rw retries? uint8 473 | +--rw target-params snmp:identifier 474 +--rw target-params* [name] 475 | +--rw name snmp:identifier 476 | +--rw (params)? 477 | +--:(v1) 478 | | +--rw v1 479 | | +--rw security-name snmp:security-name 480 | +--:(v2c) 481 | | +--rw v2c 482 | | +--rw security-name snmp:security-name 483 | +--:(usm) 484 | | +--rw usm 485 | | +--rw user-name snmp:security-name 486 | | +--rw security-level security-level 487 | +--:(tsm) 488 | +--rw tsm 489 | +--rw security-name snmp:security-name 490 | +--rw security-level security-level 491 +--rw community* [index] 492 | +--rw index snmp:identifier 493 | +--rw (name)? 494 | | +--:(text-name) 495 | | | +--rw text-name? string 496 | | +--:(binary-name) 497 | | +--rw binary-name? binary 498 | +--rw security-name snmp:security-name 499 | +--rw engine-id? snmp:engine-id 500 | +--rw context? snmp:context-name 501 | +--rw target-tag? snmp:identifier 502 +--rw vacm 503 | +--rw group* [name] 504 | | +--rw name group-name 505 | | +--rw member* [security-name] 506 | | | +--rw security-name snmp:security-name 507 | | | +--rw security-model* snmp:security-model 508 | | +--rw access* [context security-model security-level] 509 | | +--rw context snmp:context-name 510 | | +--rw context-match? enumeration 511 | | +--rw security-model snmp:security-model-or-any 512 | | +--rw security-level snmp:security-level 513 | | +--rw read-view? view-name 514 | | +--rw write-view? view-name 515 | | +--rw notify-view? view-name 516 | +--rw view* [name] 517 | +--rw name view-name 518 | +--rw include* snmp:wildcard-object-identifier 519 | +--rw exclude* snmp:wildcard-object-identifier 520 +--rw usm 521 | +--rw local 522 | | +--rw user* [name] 523 | | +--rw user-params 524 | +--rw remote* [engine-id] 525 | +--rw engine-id snmp:engine-id 526 | +--rw user* [name] 527 | +--rw user-params 528 +--rw tsm 529 +--rw use-prefix? boolean 531 The structure of "user-params" is: 533 grouping: user-params 534 +--rw user-params 535 +--rw name snmp:identifier 536 +--rw auth! 537 | +--rw (protocol) 538 | +--:(md5) 539 | | +--rw md5 540 | | +-- rw key yang:hex-string 541 | +--:(sha) 542 | +--rw sha 543 | +-- rw key yang:hex-string 544 +--rw priv! 545 +--rw (protocol) 546 +--:(des) 547 | +--rw des 548 | +-- rw key yang:hex-string 549 +--:(aes) 550 +--rw aes 551 +-- rw key yang:hex-string 553 5.2.2. NETCONF Management Security 555 The NETCONF server model defined in 556 [I-D.ietf-netconf-netconf-client-server] supports both the SSH and 557 TLS transport protocols. The SSH security grouping and TLS security 558 grouping defined in section Section 5.1.1 are reused. 560 submodule: netconf-management-security 561 +--rw netconf-management-security 562 +--rw listen {listen}? 563 | +--rw endpoint* [name] 564 | +--rw name string 565 | +--rw (transport) 566 | +--:(ssh) {ssh-listen?} 567 | | +--rw ssh-security-params 568 | +--:(tls) {tls-listen?} 569 | +--rw netconf-tls-security-params 570 +--rw call-home {call-home}? 571 +--rw netconf-client* [name] 572 +--rw (transport) 573 +--:(ssh) {ssh-call-home}? 574 | +--rw ssh-security-params 575 +--:(tls) {tls-call-home}? 576 +--rw tls-security-params 578 The structure of "netconf tls-security-params" is: 580 grouping: tls-security-params 581 +--rw tls-security-params 582 +--rw certificates 583 | +--rw certificate* [name] 584 | +--rw name? leafref 585 +--rw client-auth 586 | +--rw pinned-ca-certs? -> /ks:keystore/pinned-certificates/name 587 | +--rw pinned-client-certs? -> /ks:keystore/pinned-certificates/name 588 | +--rw cert-maps {cert-maps-function}? 589 | +--rw cert-to-name* [id] 590 | +--rw id uint32 591 | +--rw fingerprint x509c2n:tls-fingerprint 592 | +--rw map-type identityref 593 | +--rw name string 594 +--rw hello-params {tls-server-hello-params-config}? 595 +--rw tls-versions 596 | +--rw tls-version* identityref 597 +--rw cipher-suites 598 +--rw cipher-suite* identityref 600 The above structure combines the "tls-server-grouping" defined in 601 [I-D.ietf-netconf-tls-client-server] with "cert-maps" defined in 602 [RFC7407]. 604 5.3. Log Security 606 Logs record information such as user operations on devices and device 607 running status. Stored as log files on devices, logs help network 608 administrators monitor the running status of routers and diagnose 609 network faults. The log records can be outputted to console, or 610 stored locally, or outputted to remote Syslog server. The following 611 defined "log-security" module reuses the security related submodules 612 of [I-D.ietf-netmod-syslog-model], and adds access control for 613 locally stored log files. 615 module:log-security 616 +--rw log-security 617 +--rw (log-mode) 618 +--:(file)? 619 | +--rw user-level-for-read uint8 620 +--:(remote)? 621 ... 622 +--rw (transport) 623 | ... 624 | +--:(tls) 625 | +--rw tls 626 | +--rw server-auth 627 | | +--rw trusted-ca-certs? -> /ks:keystore/trusted-certificates/name 628 | | +--rw trusted-server-certs? -> /ks:keystore/trusted-certificates/name 629 | +--rw client-auth 630 | | +--rw (auth-type)? 631 | | +--:(certificate) 632 | | +--rw certificate? -> /ks:keystore/keys/key/certificates/certificate/name 633 | +--rw hello-params {tls-client-hello-params-config}? 634 | | +--rw tls-versions 635 | | | +--rw tls-version* identityref 636 | | +--rw cipher-suites 637 | | +--rw cipher-suite* identityref 638 | +--rw address? inet:host 639 | +--rw port? inet:port-number 640 +--rw signing-options! {signed-messages}? 641 +--rw cert-signers 642 +--rw cert-signer* [name] 643 | +--rw name string 644 | +--rw certificate? -> /ks:keystore/keys/key/certificates/certificate/name 645 | +--rw hash-algorithm? enumeration 646 +--rw cert-initial-repeat? uint32 647 +--rw cert-resend-delay? uint32 648 +--rw cert-resend-count? uint32 649 +--rw sig-max-delay? uint32 650 +--rw sig-number-resends? uint32 651 +--rw sig-resend-delay? uint32 652 +--rw sig-resend-count? uint32 654 5.4. File Security 656 Patches, packages, configuration files are critical system files for 657 network infrastructure devices. To provide security, only users 658 under certain security levels are allowed to access these files, but 659 cannot delete or modify them. For configuration files, only users 660 with certain configuration rights can modify them. 662 module:file-security 663 +--rw file-security 664 +--rw (file-operation) 665 +--:(local) 666 | +--rw user-level-for-execute uint8 667 | +--rw (file-type) 668 | +--:(patch) 669 | | +--rw patch-integrity-check boolean 670 | | +--rw integrity-alg identityref 671 | +--:(package) 672 | | +--rw package-integrity-check boolean 673 | | +--rw integrity-alg identityref 674 | +--:(configuration-file) 675 | +--rw user-level-for-modify uint8 676 +--:(remote-transfer) 677 +--rw (transfer-channel) 678 +--:(ftp) 679 | +--rw ftp-enable boolean 680 | +--rw ftp-server-port inet:port-number 681 | +--rw ftp-source-ip inet:host 682 | +--rw ftp-source-port inet:port-number 683 | +--rw acl*? [acl-name acl-type] 684 | +--rw acl-name string 685 | +--rw acl-type acl:acl-type 686 +--:(sftp) 687 | +--rw sftp-enable boolean 688 | +--rw sftp-server-port inet:port-number 689 | +--rw ssh-security-params 690 +--:(scp) 691 | +--rw scp-enable boolean 692 | +--rw scp-server-port inet:port-number 693 | +--rw ssh-security-params 694 +--:(ftps) 695 +--rw ftps-enable boolean 696 +--rw ftps-server-port inet:port-number 697 +--rw tls-security-params 699 6. Network Infrastructure Device Security Baseline Yang Module 701 TBD 703 7. Acknowledgements 705 8. IANA Considerations 707 This document requires no IANA actions. 709 9. Security Considerations 711 TBD 713 10. References 715 10.1. Normative References 717 [I-D.birkholz-sacm-yang-content] 718 Birkholz, H. and N. Cam-Winget, "YANG subscribed 719 notifications via SACM Statements", draft-birkholz-sacm- 720 yang-content-00 (work in progress), July 2017. 722 [I-D.dong-sacm-nid-cp-security-baseline] 723 Dong, Y. and L. Xia, "The Data Model of Network 724 Infrastructure Device Control Plane Security Baseline", 725 draft-dong-sacm-nid-cp-security-baseline-00 (work in 726 progress), September 2017. 728 [I-D.ietf-netconf-netconf-client-server] 729 Watsen, K., Wu, G., and J. Schoenwaelder, "NETCONF Client 730 and Server Models", draft-ietf-netconf-netconf-client- 731 server-04 (work in progress), July 2017. 733 [I-D.ietf-netconf-ssh-client-server] 734 Watsen, K. and G. Wu, "SSH Client and Server Models", 735 draft-ietf-netconf-ssh-client-server-03 (work in 736 progress), June 2017. 738 [I-D.ietf-netconf-tls-client-server] 739 Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and 740 TLS Servers", draft-ietf-netconf-tls-client-server-04 741 (work in progress), October 2017. 743 [I-D.ietf-netmod-acl-model] 744 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 745 "Network Access Control List (ACL) YANG Data Model", 746 draft-ietf-netmod-acl-model-14 (work in progress), October 747 2017. 749 [I-D.ietf-netmod-syslog-model] 750 Wildes, C. and K. Koushik, "A YANG Data Model for Syslog 751 Configuration", draft-ietf-netmod-syslog-model-17 (work in 752 progress), September 2017. 754 [I-D.ietf-sacm-information-model] 755 Waltermire, D., Watson, K., Kahn, C., Lorenzin, L., Cokus, 756 M., Haynes, D., and H. Birkholz, "SACM Information Model", 757 draft-ietf-sacm-information-model-10 (work in progress), 758 April 2017. 760 [I-D.xia-sacm-nid-dp-security-baseline] 761 Xia, L. and G. Zheng, "The Data Model of Network 762 Infrastructure Device Data Plane Security Baseline", 763 draft-xia-sacm-nid-dp-security-baseline-00 (work in 764 progress), September 2017. 766 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 767 System Management", RFC 7317, DOI 10.17487/RFC7317, August 768 2014, . 770 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 771 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 772 December 2014, . 774 10.2. Informative References 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, 778 DOI 10.17487/RFC2119, March 1997, 779 . 781 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 782 the Network Configuration Protocol (NETCONF)", RFC 6020, 783 DOI 10.17487/RFC6020, October 2010, 784 . 786 Authors' Addresses 788 Qiushi Lin 789 Huawei 790 Huawei Industrial Base 791 Shenzhen, Guangdong 518129 792 China 794 Email: linqiushi@huawei.com 795 Liang Xia 796 Huawei 797 101 Software Avenue, Yuhuatai District 798 Nanjing, Jiangsu 210012 799 China 801 Email: Frank.xialiang@huawei.com