idnits 2.17.1 draft-ietf-netmod-system-mgmt-07.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 == Line 230 has weird spacing: '...address ine...' == Line 245 has weird spacing: '...rw name str...' == Line 249 has weird spacing: '...address ine...' == Line 309 has weird spacing: '...gorithm str...' == Line 592 has weird spacing: '...atabase http:...' == 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 17, 2013) is 3963 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 (-03) exists of draft-ietf-netmod-iana-timezones-00 == Outdated reference: A later version (-03) exists of draft-ietf-netmod-rfc6021-bis-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-1003.1-2008' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bierman 3 Internet-Draft YumaWorks 4 Intended status: Standards Track M. Bjorklund 5 Expires: December 19, 2013 Tail-f Systems 6 June 17, 2013 8 YANG Data Model for System Management 9 draft-ietf-netmod-system-mgmt-07 11 Abstract 13 This document defines a YANG data model for the configuration and 14 identification of some common system properties within a device 15 containing a NETCONF server. This includes data node definitions for 16 system identification, time-of-day management, user management, DNS 17 resolver configuration, and some protocol operations for system 18 management. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 19, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. System Identification . . . . . . . . . . . . . . . . . . 5 59 2.2. System Time Management . . . . . . . . . . . . . . . . . . 5 60 2.3. User Authentication . . . . . . . . . . . . . . . . . . . 5 61 2.4. DNS Resolver . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.5. System Control . . . . . . . . . . . . . . . . . . . . . . 6 63 3. System Data Model . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1. System Identification . . . . . . . . . . . . . . . . . . 7 65 3.2. System Time Management . . . . . . . . . . . . . . . . . . 7 66 3.3. DNS Resolver Model . . . . . . . . . . . . . . . . . . . . 7 67 3.4. RADIUS Client Model . . . . . . . . . . . . . . . . . . . 8 68 3.5. User Authentication Model . . . . . . . . . . . . . . . . 8 69 3.5.1. SSH Public Key Authentication . . . . . . . . . . . . 9 70 3.5.2. Local User Password Authentication . . . . . . . . . . 9 71 3.5.3. RADIUS Password Authentication . . . . . . . . . . . . 10 72 3.6. System Control . . . . . . . . . . . . . . . . . . . . . . 10 73 4. System YANG module . . . . . . . . . . . . . . . . . . . . . . 11 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 76 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32 77 7.1. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 78 7.2. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 79 7.3. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 80 7.4. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 81 7.5. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 82 7.6. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 83 7.7. 06-07 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 36 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 89 1. Introduction 91 This document defines a YANG [RFC6020] data model for the 92 configuration and identification of some common properties within a 93 device containing a NETCONF server. 95 Devices that are managed by NETCONF and perhaps other mechanisms have 96 common properties that need to be configured and monitored in a 97 standard way. 99 The "ietf-system" YANG module defined in this document provides the 100 following features: 102 o system identification configuration and monitoring 104 o system time-of-day configuration and monitoring 106 o user authentication configuration 108 o local users configuration 110 o DNS resolver configuration 112 o system control operations (shutdown, restart, setting time) 114 1.1. Terminology 116 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14, [RFC2119]. 121 1.2. Tree Diagrams 123 A simplified graphical representation of the data model is used in 124 this document. The meaning of the symbols in these diagrams is as 125 follows: 127 o Brackets "[" and "]" enclose list keys. 129 o Abbreviations before data node names: "rw" means configuration 130 (read-write) and "ro" state data (read-only). 132 o Symbols after data node names: "?" means an optional node and "*" 133 denotes a "list" and "leaf-list". 135 o Parentheses enclose choice and case nodes, and case nodes are also 136 marked with a colon (":"). 138 o Ellipsis ("...") stands for contents of subtrees that are not 139 shown. 141 2. Objectives 143 2.1. System Identification 145 There are many common properties used to identify devices, operating 146 systems, software versions, etc. that need to be supported in the 147 system data module. These objects are defined as operational state 148 data and the information returned by the server is intended to be 149 specific to the device vendor. 151 Some user-configurable administrative strings are also provided, such 152 as the system location and description. 154 2.2. System Time Management 156 The management of the date and time used by the system need to be 157 supported. Use of one or more NTP servers to automatically set the 158 system date and time need to be possible. Utilization of the 159 Timezone database [RFC6557] also need to be supported. It should be 160 possible for the server, as well as clients, to configure the system 161 to use NTP. 163 2.3. User Authentication 165 The authentication mechanism need to support password authentication 166 over RADIUS, to support deployment scenarios with centralized 167 authentication servers. Additionally, local users need to be 168 supported, for scenarios when no centralized authentication server 169 exists, or for situations where the centralized authentication server 170 cannot be reached from the device. 172 Since the mandatory transport protocol for NETCONF is SSH [RFC6242] 173 the authentication model need to support SSH's "publickey" and 174 "password" authentication methods [RFC4252]. 176 The model for authentication configuration should be flexible enough 177 to support authentication methods defined by other standard documents 178 or by vendors. It should be possible for the server, as well as 179 clients, to configure the system authentication properties. 181 2.4. DNS Resolver 183 The configuration of the DNS resolver within the system containing 184 the NETCONF server is required to control how domain names are 185 resolved. An order list of DNS servers and some common parameters 186 such as the list of domains to search when resolving a host name. 188 2.5. System Control 190 A few operations are needed to support common tasks such as 191 restarting the device or setting the system date and time. 193 3. System Data Model 195 3.1. System Identification 197 The data model for system identification has the following structure: 199 +--rw system 200 +--rw contact? string 201 +--rw hostname? inet:domain-name 202 +--rw location? string 203 +--ro platform 204 +--ro os-name? string 205 +--ro os-release? string 206 +--ro os-version? string 207 +--ro machine? string 209 3.2. System Time Management 211 The data model for system time management has the following 212 structure: 214 +--rw system 215 +--rw clock 216 | +--ro current-datetime? yang:date-and-time 217 | +--ro boot-datetime? yang:date-and-time 218 | +--rw (timezone)? 219 | +--:(timezone-location) 220 | | +--rw timezone-location? ianatz:iana-timezone 221 | +--:(timezone-utc-offset) 222 | +--rw timezone-utc-offset? int16 223 +--rw ntp 224 +--rw enabled? boolean 225 +--rw server* [name] 226 +--rw name string 227 +--rw (transport) 228 | +--:(udp) 229 | +--rw udp 230 | +--rw address inet:host 231 | +--rw port? inet:port-number 232 +--rw association-type? enumeration 233 +--rw iburst? boolean 234 +--rw prefer? boolean 236 3.3. DNS Resolver Model 238 The data model for configuration of the DNS resolver has the 239 following structure: 241 +--rw system 242 +--rw dns-resolver 243 +--rw search* inet:domain-name 244 +--rw server* [name] 245 | +--rw name string 246 | +--rw (transport) 247 | +--:(udp) 248 | +--rw udp 249 | +--rw address inet:ip-address 250 | +--rw port? inet:port-number 251 +--rw options 252 +--rw timeout? uint8 253 +--rw attempts? uint8 255 3.4. RADIUS Client Model 257 The data model for configuration of the RADIUS client has the 258 following structure: 260 +--rw system 261 +--rw radius 262 +--rw server* [name] 263 | +--rw name string 264 | +--rw (transport) 265 | | +--:(udp) 266 | | +--rw udp 267 | | +--rw address inet:host 268 | | +--rw authentication-port? inet:port-number 269 | | +--rw shared-secret string 270 | +--rw authentication-type? identityref 271 +--rw options 272 +--rw timeout? uint8 273 +--rw attempts? uint8 275 3.5. User Authentication Model 277 This document defines three authentication methods for use with 278 NETCONF: 280 o publickey for local users over SSH 282 o password for local users over any transport 284 o password for RADIUS users over any transport 286 Additional methods can be defined by other standard documents or by 287 vendors. 289 This document defines two optional YANG features, "local-users" and 290 "radius-authentication", which the server advertises to indicate 291 support for configuring local users on the device, and support for 292 using RADIUS for authentication, respectively. 294 The authentication parameters defined in this document are primarily 295 used to configure authentication of NETCONF users, but MAY also be 296 used by other interfaces, e.g., a Command Line Interface or a Web- 297 based User Interface. 299 The data model for user authentication has the following structure: 301 +--rw system 302 +--rw authentication 303 +--rw user-authentication-order* identityref 304 +--rw user* [name] 305 +--rw name string 306 +--rw password? crypt-hash 307 +--rw ssh-key* [name] 308 +--rw name string 309 +--rw algorithm string 310 +--rw key-data binary 312 3.5.1. SSH Public Key Authentication 314 If the NETCONF server advertises the "local-users" feature, 315 configuration of local users and their SSH public keys is supported 316 in the /system/authentication/user list. 318 Public key authentication is requested by the SSH client. If the 319 "local-users" feature is supported, then when a NETCONF client starts 320 an SSH session towards the server using the "publickey" 321 authentication "method name" [RFC4252], the SSH server looks up the 322 user name given in the SSH authentication request in the /system/ 323 authentication/user list, and verifies the key as described in 324 [RFC4253]. 326 3.5.2. Local User Password Authentication 328 If the NETCONF server advertises the "local-users" feature, 329 configuration of local users and their passwords is supported in the 330 /system/authentication/user list. 332 For NETCONF transport protocols that support password authentication, 333 the leaf-list "user-authentication-order" is used to control if local 334 user password authentication should be used. 336 In SSH, password authentication is requested by the client. Other 337 NETCONF transport protocols MAY also support password authentication. 339 When local user password authentication is requested, the NETCONF 340 transport looks up the user name provided by the client in the 341 /system/authentication/user list, and verifies the password. 343 3.5.3. RADIUS Password Authentication 345 If the NETCONF server advertises the "radius-authentication" feature, 346 the device supports user authentication using RADIUS. 348 For NETCONF transport protocols that support password authentication, 349 the leaf-list "user-authentication-order" is used to control if 350 RADIUS password authentication should be used. 352 In SSH, password authentication is requested by the client. Other 353 NETCONF transport protocols MAY also support password authentication. 355 3.6. System Control 357 Two protocol operations are included to restart or shutdown the 358 system. The 'system-restart' operation can be used to restart the 359 entire system (not just the NETCONF server). The 'system-shutdown' 360 operation can be used to power off the entire system. 362 4. System YANG module 364 This YANG module imports YANG extensions from [RFC6536], and imports 365 YANG types from [I-D.ietf-netmod-rfc6021-bis] and 366 [I-D.ietf-netmod-iana-timezones]. It also references [RFC1321], 367 [RFC2865], [RFC3418], [RFC5607], [IEEE-1003.1-2008], and 368 [FIPS.180-3.2008]. 370 RFC Ed.: update the date below with the date of RFC publication and 371 remove this note. 373 file "ietf-system@2013-06-17.yang" 375 module ietf-system { 376 namespace "urn:ietf:params:xml:ns:yang:ietf-system"; 377 prefix "sys"; 379 import ietf-yang-types { 380 prefix yang; 381 } 383 import ietf-inet-types { 384 prefix inet; 385 } 387 import ietf-netconf-acm { 388 prefix nacm; 389 } 391 import iana-timezones { 392 prefix ianatz; 393 } 395 organization 396 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 398 contact 399 "WG Web: 400 WG List: 402 WG Chair: David Kessens 403 405 WG Chair: Juergen Schoenwaelder 406 408 Editor: Andy Bierman 409 411 Editor: Martin Bjorklund 412 "; 414 description 415 "This module contains a collection of YANG definitions for the 416 configuration and identification of some common system 417 properties within a device containing a NETCONF server. This 418 includes data node definitions for system identification, 419 time-of-day management, user management, DNS resolver 420 configuration, and some protocol operations for system 421 management. 423 Copyright (c) 2013 IETF Trust and the persons identified as 424 authors of the code. All rights reserved. 426 Redistribution and use in source and binary forms, with or 427 without modification, is permitted pursuant to, and subject 428 to the license terms contained in, the Simplified BSD License 429 set forth in Section 4.c of the IETF Trust's Legal Provisions 430 Relating to IETF Documents 431 (http://trustee.ietf.org/license-info). 433 This version of this YANG module is part of RFC XXXX; see 434 the RFC itself for full legal notices."; 436 // RFC Ed.: replace XXXX with actual RFC number and remove this 437 // note. 439 // RFC Ed.: remove this note 440 // Note: extracted from draft-ietf-netmod-system-mgmt-07.txt 442 // RFC Ed.: update the date below with the date of RFC publication 443 // and remove this note. 444 revision "2013-06-17" { 445 description 446 "Initial revision."; 447 reference 448 "RFC XXXX: A YANG Data Model for System Management"; 449 } 451 /* 452 * Typedefs 453 */ 455 typedef crypt-hash { 456 type string { 457 pattern 458 '$0$.*' 460 + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}' 461 + '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}' 462 + '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}'; 463 } 464 description 465 "The crypt-hash type is used to store passwords using 466 a hash function. The algorithms for applying the hash 467 function and encoding the result are implemented in 468 various UNIX systems as the function crypt(3). 470 A value of this type matches one of the forms: 472 $0$ 473 $$$ 474 $$$$ 476 The '$0$' prefix signals that the value is clear text. When 477 such a value is received by the server, a hash value is 478 calculated, and the string '$$$' or 479 $$$$ is prepended to the result. This 480 value is stored in the configuration data store. 482 If a value starting with '$$', where is not '0', is 483 received, the server knows that the value already represents a 484 hashed value, and stores it as is in the data store. 486 When a server needs to verify a password given by a user, it 487 finds the stored password hash string for that user, extracts 488 the salt, and calculates the hash with the salt and given 489 password as input. If the calculated hash value is the same 490 as the stored value, the password given by the client is 491 accepted. 493 This type defines the following hash functions: 495 id | hash function | feature 496 ---+---------------+------------------- 497 1 | MD5 | crypt-hash-md5 498 5 | SHA-256 | crypt-hash-sha-256 499 6 | SHA-512 | crypt-hash-sha-512 501 The server indicates support for the different hash functions 502 by advertising the corresponding feature."; 503 reference 504 "IEEE Std 1003.1-2008 - crypt() function 505 Wikipedia: http://en.wikipedia.org/wiki/Crypt_(C) 506 RFC 1321: The MD5 Message-Digest Algorithm 507 FIPS.180-3.2008: Secure Hash Standard"; 509 } 511 /* 512 * Features 513 */ 515 feature radius { 516 description 517 "Indicates that the device can be configured as a RADIUS 518 client."; 519 reference 520 "RFC 2865: Remote Authentication Dial In User Service " 521 + "(RADIUS)"; 522 } 524 feature authentication { 525 description 526 "Indicates that the device supports configuration 527 for user authentication."; 528 } 530 feature local-users { 531 if-feature authentication; 532 description 533 "Indicates that the device supports configuration of 534 local user authentication."; 535 } 537 feature radius-authentication { 538 if-feature radius; 539 if-feature authentication; 540 description 541 "Indicates that the device supports configuration of user 542 authentication over RADIUS."; 543 reference 544 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 545 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 546 Authorization for Network Access Server (NAS) 547 Management"; 548 } 550 feature crypt-hash-md5 { 551 description 552 "Indicates that the device supports the MD5 553 hash function in 'crypt-hash' values"; 554 reference "RFC 1321: The MD5 Message-Digest Algorithm"; 555 } 556 feature crypt-hash-sha-256 { 557 description 558 "Indicates that the device supports the SHA-256 559 hash function in 'crypt-hash' values"; 560 reference "FIPS.180-3.2008: Secure Hash Standard"; 561 } 563 feature crypt-hash-sha-512 { 564 description 565 "Indicates that the device supports the SHA-512 566 hash function in 'crypt-hash' values"; 567 reference "FIPS.180-3.2008: Secure Hash Standard"; 568 } 570 feature ntp { 571 description 572 "Indicates that the device can be configured 573 to use one or more NTP servers to set the 574 system date and time."; 575 } 577 feature ntp-udp-port { 578 description 579 "Indicates that the device supports the configuration of 580 the UDP port for NTP servers. 582 This is a 'feature' since many implementations do not support 583 any other port than the default port."; 584 } 586 feature timezone-location { 587 description 588 "Indicates that the local timezone on the device 589 can be configured to use the TZ database 590 to set the timezone and manage daylight savings time."; 591 reference 592 "TZ Database http://www.twinsun.com/tz/tz-link.htm 593 Maintaining the Timezone Database 594 RFC 6557 (BCP 175)"; 595 } 597 feature dns-udp-port { 598 description 599 "Indicates that the device supports the configuration of 600 the UDP port for DNS servers. 602 This is a 'feature' since many implementations do not support 603 any other port than the default port."; 605 } 607 /* 608 * Identities 609 */ 611 identity authentication-method { 612 description 613 "Base identity for user authentication methods."; 614 } 616 identity radius { 617 base authentication-method; 618 description 619 "Indicates user authentication using RADIUS."; 620 reference 621 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 622 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 623 Authorization for Network Access Server (NAS) 624 Management"; 625 } 627 identity local-users { 628 base authentication-method; 629 description 630 "Indicates password-based authentication of locally 631 configured users."; 632 } 634 identity radius-authentication-type { 635 description 636 "Base identity for RADIUS authentication types."; 637 } 639 identity radius-pap { 640 base radius-authentication-type; 641 description 642 "The device requests PAP authentication from the RADIUS 643 server."; 644 reference 645 "RFC 2865: Remote Authentication Dial In User Service"; 646 } 648 identity radius-chap { 649 base radius-authentication-type; 650 description 651 "The device requests CHAP authentication from the RADIUS 652 server."; 654 reference 655 "RFC 2865: Remote Authentication Dial In User Service"; 656 } 658 /* 659 * Top-level container 660 */ 662 container system { 663 description 664 "System group configuration."; 666 leaf contact { 667 type string; 668 description 669 "The administrator contact information for the system. 670 The server MAY restrict the size and characters in 671 order to maintain compatibility with the sysContact 672 MIB object."; 673 reference 674 "RFC 3418 - Management Information Base (MIB) for the 675 Simple Network Management Protocol (SNMP) 676 SNMPv2-MIB.sysContact"; 677 } 678 leaf hostname { 679 type inet:domain-name; 680 description 681 "The name of the host. This name can be a single domain 682 label, or the fully qualified domain name of the host."; 683 } 684 leaf location { 685 type string; 686 description 687 "The system location. The server MAY restrict the size 688 and characters in order to maintain compatibility with 689 the sysLocation MIB object."; 690 reference 691 "RFC 3418 - Management Information Base (MIB) for the 692 Simple Network Management Protocol (SNMP) 693 SNMPv2-MIB.sysLocation"; 694 } 695 container platform { 696 config false; 697 description 698 "Contains vendor-specific information for 699 identifying the system platform and operating system."; 700 reference 701 "IEEE Std 1003.1-2008 - sys/utsname.h"; 703 leaf os-name { 704 type string; 705 description 706 "The name of the operating system in use, 707 for example 'Linux'"; 708 reference 709 "IEEE Std 1003.1-2008 - utsname.sysname"; 710 } 711 leaf os-release { 712 type string; 713 description 714 "The current release level of the operating 715 system in use. This string MAY indicate 716 the OS source code revision."; 717 reference 718 "IEEE Std 1003.1-2008 - utsname.release"; 719 } 720 leaf os-version { 721 type string; 722 description 723 "The current version level of the operating 724 system in use. This string MAY indicate 725 the specific OS build date and target variant 726 information."; 727 reference 728 "IEEE Std 1003.1-2008 - utsname.version"; 729 } 730 leaf machine { 731 type string; 732 description 733 "A vendor-specific identifier string representing 734 the hardware in use."; 735 reference 736 "IEEE Std 1003.1-2008 - utsname.machine"; 737 } 738 } 739 container clock { 740 description 741 "Configuration and monitoring of the system 742 date and time properties."; 744 leaf current-datetime { 745 type yang:date-and-time; 746 config false; 747 description 748 "The current system date and time."; 749 } 750 leaf boot-datetime { 751 type yang:date-and-time; 752 config false; 753 description 754 "The system date and time when the system last restarted."; 755 } 756 choice timezone { 757 description 758 "The system timezone information."; 760 case timezone-location { 761 if-feature timezone-location; 762 leaf timezone-location { 763 type ianatz:iana-timezone; 764 description 765 "The TZ database location identifier string 766 to use for the system, such as 'Europe/Stockholm'."; 767 } 768 } 769 case timezone-utc-offset { 770 leaf timezone-utc-offset { 771 type int16 { 772 range "-1500 .. 1500"; 773 } 774 units "minutes"; 775 description 776 "The number of minutes to add to UTC time to 777 identify the timezone for this system. For example, 778 'UTC - 8:00 hours' would be represented as '-480'. 779 Note that automatic daylight savings time adjustment 780 is not provided, if this object is used."; 781 } 782 } 783 } 784 } 786 container ntp { 787 if-feature ntp; 788 description 789 "Configuration of the NTP client."; 791 leaf enabled { 792 type boolean; 793 default true; 794 description 795 "Indicates that the system should attempt 796 to synchronize the system clock with an 797 NTP server from the 'ntp/server' list."; 798 } 799 list server { 800 key name; 801 description 802 "List of NTP servers to use for 803 system clock synchronization. If '/system/ntp/enabled' 804 is 'true', then the system will attempt to 805 contact and utilize the specified NTP servers."; 807 leaf name { 808 type string; 809 description 810 "An arbitrary name for the NTP server."; 811 } 812 choice transport { 813 mandatory true; 814 description 815 "The transport protocol specific parameters for this 816 server. 818 It is expected that new case statements will be added 819 over time to support other transport protocols."; 820 case udp { 821 container udp { 822 description 823 "Contains UDP specific configuration parameters 824 for NTP."; 825 leaf address { 826 type inet:host; 827 mandatory true; 828 description 829 "The address of the NTP server."; 830 } 831 leaf port { 832 if-feature ntp-udp-port; 833 type inet:port-number; 834 default 123; 835 description 836 "The port number of the NTP server."; 837 } 838 } 839 } 840 } 841 leaf association-type { 842 type enumeration { 843 enum server { 844 description 845 "Use client association mode. This device 846 will not provide synchronization to the 847 configured NTP server."; 848 } 849 enum peer { 850 description 851 "Use symmetric active association mode. 852 This device may provide synchronization 853 to the configured NTP server."; 854 } 855 enum pool { 856 description 857 "Use client association mode with one or 858 more of the NTP servers found by DNS 859 resolution of the domain name given by 860 the 'address' leaf. This device will not 861 provide synchronization to the servers."; 862 } 863 } 864 default server; 865 description 866 "The desired association type for this NTP server."; 867 } 868 leaf iburst { 869 type boolean; 870 default false; 871 description 872 "Indicates whether this server should enable burst 873 synchronization or not."; 874 } 875 leaf prefer { 876 type boolean; 877 default false; 878 description 879 "Indicates whether this server should be preferred 880 or not."; 881 } 882 } 883 } 885 container dns-resolver { 886 description 887 "Configuration of the DNS resolver."; 889 leaf-list search { 890 type inet:domain-name; 891 ordered-by user; 892 description 893 "An ordered list of domains to search when resolving 894 a host name."; 896 } 897 list server { 898 key name; 899 ordered-by user; 900 description 901 "List of the DNS servers that the resolver should query. 903 When the resolver is invoked by a calling application, it 904 sends the query to the first name server in this list. If 905 no response has been received within 'timeout' seconds, 906 the resolver continues with the next server in the list. 907 If no response is received from any server, the resolver 908 continues with the first server again. When the resolver 909 has traversed the list 'attempts' times without receiving 910 any response, it gives up and returns an error to the 911 calling application. 913 Implementations MAY limit the number of entries in this 914 list."; 916 leaf name { 917 type string; 918 description 919 "An arbitrary name for the DNS server."; 920 } 921 choice transport { 922 mandatory true; 923 description 924 "The transport protocol specific parameters for this 925 server. 927 It is expected that new case statements will be added 928 over time to support other transport protocols."; 929 case udp { 930 container udp { 931 description 932 "Contains UDP specific configuration parameters 933 for DNS."; 934 leaf address { 935 type inet:ip-address; 936 mandatory true; 937 description 938 "The address of the DNS server."; 939 } 940 leaf port { 941 if-feature dns-udp-port; 942 type inet:port-number; 943 default 53; 944 description 945 "The port number of the DNS server."; 946 } 947 } 948 } 949 } 950 } 951 container options { 952 description 953 "Resolver options. The set of available options has been 954 limited to those that are generally available across 955 different resolver implementations, and generally 956 useful."; 957 leaf timeout { 958 type uint8 { 959 range "1..max"; 960 } 961 units "seconds"; 962 default "5"; 963 description 964 "The amount of time the resolver will wait for a 965 response from each remote name server before 966 retrying the query via a different name server."; 967 } 968 leaf attempts { 969 type uint8 { 970 range "1..max"; 971 } 972 default "2"; 973 description 974 "The number of times the resolver will send a query to 975 all its name servers before giving up and returning an 976 error to the calling application."; 977 } 978 } 979 } 981 container radius { 982 if-feature radius; 984 description 985 "Configuration of the RADIUS client."; 987 list server { 988 key name; 989 ordered-by user; 990 description 991 "List of RADIUS servers used by the device. 993 When the RADIUS client is invoked by a calling 994 application, it sends the query to the first server in 995 this list. If no response has been received within 996 'timeout' seconds, the client continues with the next 997 server in the list. If no response is received from any 998 server, the client continues with the first server again. 999 When the client has traversed the list 'attempts' times 1000 without receiving any response, it gives up and returns an 1001 error to the calling application."; 1003 leaf name { 1004 type string; 1005 description 1006 "An arbitrary name for the RADIUS server."; 1007 } 1008 choice transport { 1009 mandatory true; 1010 description 1011 "The transport protocol specific parameters 1012 for this server. It is expected that new 1013 case statements will be added over time to 1014 support other transport protocols."; 1015 case udp { 1016 container udp { 1017 description 1018 "Contains UDP specific configuration parameters 1019 for RADIUS."; 1020 leaf address { 1021 type inet:host; 1022 mandatory true; 1023 description 1024 "The address of the RADIUS server."; 1025 } 1026 leaf authentication-port { 1027 type inet:port-number; 1028 default "1812"; 1029 description 1030 "The port number of the RADIUS server."; 1031 } 1032 leaf shared-secret { 1033 type string; 1034 mandatory true; 1035 nacm:default-deny-all; 1036 description 1037 "The shared secret which is known to both the 1038 RADIUS client and server."; 1039 reference 1040 "RFC 2865: Remote Authentication Dial In User 1041 Service"; 1042 } 1043 } 1044 } 1045 } 1046 leaf authentication-type { 1047 type identityref { 1048 base radius-authentication-type; 1049 } 1050 default radius-pap; 1051 description 1052 "The authentication type requested from the RADIUS 1053 server."; 1054 } 1055 } 1056 container options { 1057 description 1058 "RADIUS client options."; 1060 leaf timeout { 1061 type uint8 { 1062 range "1..max"; 1063 } 1064 units "seconds"; 1065 default "5"; 1066 description 1067 "The number of seconds the device will wait for a 1068 response from each RADIUS server before trying with a 1069 different server."; 1070 } 1071 leaf attempts { 1072 type uint8 { 1073 range "1..max"; 1074 } 1075 default "2"; 1076 description 1077 "The number of times the device will send a query to 1078 all its RADIUS servers before giving up."; 1079 } 1080 } 1081 } 1083 container authentication { 1084 nacm:default-deny-write; 1085 if-feature authentication; 1087 description 1088 "The authentication configuration subtree."; 1090 leaf-list user-authentication-order { 1091 type identityref { 1092 base authentication-method; 1093 } 1094 must '(. != "sys:radius" or ../../radius/server)' { 1095 error-message 1096 "When 'radius' is used, a RADIUS server" 1097 + " must be configured."; 1098 description 1099 "When 'radius' is used as an authentication method, 1100 a RADIUS server must be configured."; 1101 } 1102 ordered-by user; 1104 description 1105 "When the device authenticates a user with 1106 a password, it tries the authentication methods in this 1107 leaf-list in order. If authentication with one method 1108 fails, the next method is used. If no method succeeds, 1109 the user is denied access. 1111 If the 'radius-authentication' feature is advertised by 1112 the NETCONF server, the 'radius' identity can be added to 1113 this list. 1115 If the 'local-users' feature is advertised by the 1116 NETCONF server, the 'local-users' identity can be 1117 added to this list."; 1118 } 1120 list user { 1121 if-feature local-users; 1122 key name; 1123 description 1124 "The list of local users configured on this device."; 1126 leaf name { 1127 type string; 1128 description 1129 "The user name string identifying this entry."; 1130 } 1131 leaf password { 1132 type crypt-hash; 1133 description 1134 "The password for this entry."; 1135 } 1136 list ssh-key { 1137 key name; 1138 description 1139 "A list of public SSH keys for this user."; 1140 reference 1141 "RFC 4253: The Secure Shell (SSH) Transport Layer 1142 Protocol"; 1144 leaf name { 1145 type string; 1146 description 1147 "An arbitrary name for the ssh key."; 1148 } 1149 leaf algorithm { 1150 type string; 1151 mandatory true; 1152 description 1153 "The public key algorithm name for this ssh key. 1155 Valid values are the values in the IANA Secure Shell 1156 (SSH) Protocol Parameters registry, Public Key 1157 Algorithm Names"; 1158 reference 1159 "IANA Secure Shell (SSH) Protocol Parameters registry, 1160 Public Key Algorithm Names"; 1161 } 1162 leaf key-data { 1163 type binary; 1164 mandatory true; 1165 description 1166 "The binary key data for this ssh key."; 1167 } 1168 } 1169 } 1170 } 1171 } 1173 rpc set-current-datetime { 1174 nacm:default-deny-all; 1175 description 1176 "Set the /system/clock/current-datetime leaf 1177 to the specified value. 1179 If the system is using NTP (i.e., /system/ntp/enabled 1180 is set to 'true'), then this operation will 1181 fail with error-tag 'operation-failed', 1182 and error-app-tag value of 'ntp-active'"; 1183 input { 1184 leaf current-datetime { 1185 type yang:date-and-time; 1186 mandatory true; 1187 description 1188 "The current system date and time."; 1189 } 1190 } 1191 } 1193 rpc system-restart { 1194 nacm:default-deny-all; 1195 description 1196 "Request that the entire system be restarted immediately. 1197 A server SHOULD send an rpc reply to the client before 1198 restarting the system."; 1199 } 1201 rpc system-shutdown { 1202 nacm:default-deny-all; 1203 description 1204 "Request that the entire system be shut down immediately. 1205 A server SHOULD send an rpc reply to the client before 1206 shutting down the system."; 1207 } 1209 } 1211 1213 5. IANA Considerations 1215 This document registers one URI in the IETF XML registry [RFC3688]. 1216 Following the format in RFC 3688, the following registration is 1217 requested to be made. 1219 URI: urn:ietf:params:xml:ns:yang:ietf-system 1220 Registrant Contact: The NETMOD WG of the IETF. 1221 XML: N/A, the requested URI is an XML namespace. 1223 This document registers one YANG module in the YANG Module Names 1224 registry [RFC6020]. 1226 name: ietf-system 1227 namespace: urn:ietf:params:xml:ns:yang:ietf-system 1228 prefix: sys 1229 reference: RFC XXXX 1231 6. Security Considerations 1233 The YANG module defined in this memo is designed to be accessed via 1234 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1235 secure transport layer and the mandatory-to-implement secure 1236 transport is SSH [RFC6242]. Authorization for access to specific 1237 portions of conceptual data and operations within this module is 1238 provided by the NETCONF access control model (NACM) [RFC6536]. 1240 There are a number of data nodes defined in this YANG module which 1241 are writable/creatable/deletable (i.e., config true, which is the 1242 default). These data nodes may be considered sensitive or vulnerable 1243 in some network environments. Write operations (e.g., edit-config) 1244 to these data nodes without proper protection can have a negative 1245 effect on network operations. These are the subtrees and data nodes 1246 and their sensitivity/vulnerability: 1248 o /system/clock/timezone: This choice contains the objects used to 1249 control the timezone used by the device. 1251 o /system/ntp: This container contains the objects used to control 1252 the Network Time Protocol servers used by the device. 1254 o /system/dns-resolver: This container contains the objects used to 1255 control the Domain Name System servers used by the device. 1257 o /system/radius: This container contains the objects used to 1258 control the Remote Authentication Dial-In User Service servers 1259 used by the device. 1261 o /system/authentication/user-authentication-order: This leaf 1262 controls how user login attempts are authenticated by the device. 1264 o /system/authentication/user: This list contains the local users 1265 enabled on the system. 1267 Some of the readable data nodes in this YANG module may be considered 1268 sensitive or vulnerable in some network environments. It is thus 1269 important to control read access (e.g., via get, get-config, or 1270 notification) to these data nodes. These are the subtrees and data 1271 nodes and their sensitivity/vulnerability: 1273 o /system/platform: This container has objects which may help 1274 identify the specific NETCONF server and/or operating system 1275 implementation used on the device. 1277 o /system/authentication/user: This list has objects that may help 1278 identify the specific user names and password information in use 1279 on the device. 1281 Some of the RPC operations in this YANG module may be considered 1282 sensitive or vulnerable in some network environments. It is thus 1283 important to control access to these operations. These are the 1284 operations and their sensitivity/vulnerability: 1286 o set-current-datetime: Changes the current date and time on the 1287 device. 1289 o system-restart: Reboots the device. 1291 o system-shutdown: Shuts down the device. 1293 7. Change Log 1295 -- RFC Ed.: remove this section before publication. 1297 7.1. 00-01 1299 o added configuration-source identities 1301 o added configuration-source leaf to ntp and dns (via grouping) to 1302 choose configuration source 1304 o added association-type, iburst, prefer, and true leafs to the ntp- 1305 server list 1307 o extended the ssh keys for a user to a list of keys. support all 1308 defined key algorithms, not just dsa and rsa 1310 o clarified timezone-utc-offset description-stmt 1312 o removed '/system/ntp/server/true' leaf from data model 1314 7.2. 01-02 1316 o added default-stmts to ntp-server/iburst and ntp-server/prefer 1317 leafs 1319 o changed timezone-location leaf to use iana-timezone typedef 1320 instead of a string 1322 7.3. 02-03 1324 o removed configuration-source identities and leafs 1326 7.4. 03-04 1328 o removed ndots dns resolver option 1330 o added radius-authentication-type identity, and identities for pap 1331 and chap, and a leaf to control which authentication type to use 1332 when communicating with the radius server 1334 o made 0 an invalid value for timeouts and attempts 1336 7.5. 04-05 1338 o updated tree diagram explanation text 1340 7.6. 05-06 1342 o changed ntp/use-ntp to ntp/enabled 1344 o changed ntp/ntp-server to ntp/server 1346 o removed /system/platform/nodename leaf 1348 o changed /system/name to /system/hostname 1350 o simplified must expression in user-authentication-order 1352 o added optional rounds to sha hash definition 1354 o clarified the crypt-hash description 1356 o clarified ntp descriptions 1358 o clarified YANG module description to indicate that some system 1359 properties are supported, not the entire system 1361 o clarified that system identification values are vendor specific, 1362 not the data node objects 1364 o clarified sec. 2.2 and 2.3 to indicate that the server should also 1365 be capable of configuring these properties 1367 o changed /system/dns/search from inet:host to inet:domain-name 1369 o changed RFC6021 reference to 6021-bis 1371 o changed /system/platform/nodename to /system/platform/hostname 1373 o changed /system/radius/server/{leafs} to be within a choice and 1374 'udp' case statement so other transport specific parameters can 1375 augment this list or they can be added by the WG to a future 1376 version of this module. {leafs} are authentication-port and 1377 shared-secret. 1379 o updated YANG tree diagrams for objects added in -05 and -06 1381 7.7. 06-07 1383 o updated the Abstract and Introduction 1385 o updated Tree diagram notation 1386 o identify all external servers (dns, ntp, radius) by name instead 1387 of address, in order to make the data model extensible for 1388 additional transport protocol. 1390 o updated the Security Considerations section with a reference to 1391 NACM. 1393 8. References 1395 8.1. Normative References 1397 [FIPS.180-3.2008] 1398 National Institute of Standards and Technology, "Secure 1399 Hash Standard", FIPS PUB 180-3, October 2008, . 1403 [I-D.ietf-netmod-iana-timezones] 1404 Lange, J., "IANA Timezone Database YANG Module", 1405 draft-ietf-netmod-iana-timezones-00 (work in progress), 1406 July 2012. 1408 [I-D.ietf-netmod-rfc6021-bis] 1409 Schoenwaelder, J., "Common YANG Data Types", 1410 draft-ietf-netmod-rfc6021-bis-02 (work in progress), 1411 May 2013. 1413 [IEEE-1003.1-2008] 1414 Institute of Electrical and Electronics Engineers, 1415 "POSIX.1-2008", IEEE Standard 1003.1, March 2008. 1417 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1418 April 1992. 1420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1421 Requirement Levels", BCP 14, RFC 2119, March 1997. 1423 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1424 "Remote Authentication Dial In User Service (RADIUS)", 1425 RFC 2865, June 2000. 1427 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1428 Simple Network Management Protocol (SNMP)", STD 62, 1429 RFC 3418, December 2002. 1431 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1432 Authentication Protocol", RFC 4252, January 2006. 1434 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1435 Transport Layer Protocol", RFC 4253, January 2006. 1437 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 1438 User Service (RADIUS) Authorization for Network Access 1439 Server (NAS) Management", RFC 5607, July 2009. 1441 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1442 Network Configuration Protocol (NETCONF)", RFC 6020, 1443 October 2010. 1445 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1446 and A. Bierman, Ed., "Network Configuration Protocol 1447 (NETCONF)", RFC 6241, June 2011. 1449 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1450 Shell (SSH)", RFC 6242, June 2011. 1452 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1453 Protocol (NETCONF) Access Control Model", RFC 6536, 1454 March 2012. 1456 8.2. Informative References 1458 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1459 January 2004. 1461 [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the 1462 Time Zone Database", BCP 175, RFC 6557, February 2012. 1464 Authors' Addresses 1466 Andy Bierman 1467 YumaWorks 1469 Email: andy@yumaworks.com 1471 Martin Bjorklund 1472 Tail-f Systems 1474 Email: mbj@tail-f.com