idnits 2.17.1 draft-ietf-netmod-system-mgmt-02.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 187 has weird spacing: '...address ine...' == Line 526 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 (July 11, 2012) is 4297 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) ** Downref: Normative reference to an Experimental draft: draft-lange-netmod-iana-timezones (ref. 'I-D.lange-netmod-iana-timezones') -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-1003.1-2008' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 4 errors (**), 0 flaws (~~), 4 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: January 12, 2013 Tail-f Systems 6 July 11, 2012 8 YANG Data Model for System Management 9 draft-ietf-netmod-system-mgmt-02 11 Abstract 13 This document defines a YANG data model for the configuration and 14 identification of the management system of a device. 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 January 12, 2013. 33 Copyright Notice 35 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. System Identification . . . . . . . . . . . . . . . . . . 4 55 2.2. System Time Management . . . . . . . . . . . . . . . . . . 4 56 2.3. User Authentication . . . . . . . . . . . . . . . . . . . 4 57 3. System Data Model . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. System Identification . . . . . . . . . . . . . . . . . . 5 59 3.2. System Time Management . . . . . . . . . . . . . . . . . . 5 60 3.3. DNS Resolver Model . . . . . . . . . . . . . . . . . . . . 5 61 3.4. RADIUS Client Model . . . . . . . . . . . . . . . . . . . 6 62 3.5. User Authentication Model . . . . . . . . . . . . . . . . 6 63 3.5.1. SSH Public Key Authentication . . . . . . . . . . . . 7 64 3.5.2. Local User Password Authentication . . . . . . . . . . 7 65 3.5.3. RADIUS Password Authentication . . . . . . . . . . . . 7 66 3.6. System Control . . . . . . . . . . . . . . . . . . . . . . 8 67 4. System YANG module . . . . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 70 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 28 71 7.1. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 72 7.2. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 73 8. Normative References . . . . . . . . . . . . . . . . . . . . . 29 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 76 1. Introduction 78 This document defines a YANG [RFC6020] data model for the 79 configuration and identification of the management system of a 80 device. 82 Devices that are managed by NETCONF and perhaps other mechanisms have 83 common properties that need to be configured and monitored in a 84 standard way. 86 The YANG module defined in this document provides the following 87 features: 89 o system administrative data configuration 91 o system identification monitoring 93 o system time-of-day configuration and monitoring 95 o user authentication configuration 97 o local users configuration 99 1.1. Terminology 101 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14, [RFC2119]. 106 1.1.1. Terms 108 The following terms are used within this document: 110 o system: This term refers to the embodiment of the entire set of 111 management interfaces that a single NETCONF server is supporting 112 at a given moment. The set of physical entities managed by a 113 single NETCONF server can be static or it can change dynamically. 115 2. Objectives 117 2.1. System Identification 119 There are many common properties used to identify devices, operating 120 systems, software versions, etc. that need to be supported in the 121 system data module. These objects are defined as operational data 122 and intended to be specific to the device vendor. 124 Some user-configurable administrative strings are also provided such 125 as the system location and description. 127 2.2. System Time Management 129 The management of the date and time used by the system need to be 130 supported. Use of one or more NTP servers to automatically set the 131 system date and time need to be possible. Utilization of the 132 Timezone database [RFC6557] also need to be supported. 134 2.3. User Authentication 136 The authentication mechanism need to support password authentication 137 over RADIUS, to support deployment scenarios with centralized 138 authentication servers. Additionally, local users need to be 139 supported, for scenarios when no centralized authentication server 140 exists, or for situations where the centralized authentication server 141 cannot be reached from the device. 143 Since the mandatory transport protocol for NETCONF is SSH [RFC6242] 144 the authentication model need to support SSH's "publickey" and 145 "password" authentication methods [RFC4252]. 147 The model for authentication configuration should be flexible enough 148 to support authentication methods defined by other standard documents 149 or by vendors. 151 3. System Data Model 153 3.1. System Identification 155 The data model for system identification has the following structure: 157 +--rw system 158 +--rw contact? string 159 +--rw name? string 160 +--rw location? string 161 +--ro platform 162 +--ro os-name? string 163 +--ro os-release? string 164 +--ro os-version? string 165 +--ro machine? string 166 +--ro nodename? string 168 3.2. System Time Management 170 The data model for system time management has the following 171 structure: 173 +--rw system 174 +--rw clock 175 | +--ro current-datetime? yang:date-and-time 176 | +--ro boot-datetime? yang:date-and-time 177 | +--rw (timezone)? 178 | +--:(timezone-location) 179 | | +--rw timezone-location? string 180 | +--:(timezone-utc-offset) 181 | +--rw timezone-utc-offset? int16 182 +--rw ntp 183 +--rw use-ntp? boolean 184 +--rw configuration-source* identityref 185 +--rw ntp-server [address] 186 +--rw association-type? enumeration 187 +--rw address inet:host 188 +--rw enabled? boolean 189 +--rw iburst? boolean 190 +--rw prefer? boolean 192 3.3. DNS Resolver Model 194 The data model for configuration of the DNS resolver has the 195 following structure: 197 +--rw system 198 +--rw dns 199 +--rw configuration-source* identityref 200 +--rw search* inet:host 201 +--rw server* inet:ip-address 202 +--rw options 203 +--rw ndots? uint8 204 +--rw timeout? uint8 205 +--rw attempts? uint8 207 3.4. RADIUS Client Model 209 The data model for configuration of the RADIUS client has the 210 following structure: 212 +--rw system 213 +--rw radius 214 +--rw server [address] 215 | +--rw address inet:host 216 | +--rw authentication-port? inet:port-number 217 | +--rw shared-secret? string 218 +--rw options 219 +--rw timeout? uint8 220 +--rw attempts? uint8 222 3.5. User Authentication Model 224 This document defines three authentication methods for use with 225 NETCONF: 227 o publickey for local users over SSH 229 o password for local users over any transport 231 o password for RADIUS users over any transport 233 Additional methods can be defined by other standard documents or by 234 vendors. 236 This document defines two optional YANG features, "local-users" and 237 "radius-authentication", which the server advertises to indicate 238 support for configuring local users on the device, and support for 239 using RADIUS for authentication, respectively. 241 The authentication parameters defined in this document are primarily 242 used to configure authentication of NETCONF users, but MAY also be 243 used by other interfaces, e.g., a Command Line Interface or a Web- 244 based User Interface. 246 The data model for user authentication has the following structure: 248 +--rw system 249 +--rw authentication 250 +--rw user-authentication-order* identityref 251 +--rw user [name] 252 +--rw name string 253 +--rw password? crypt-hash 254 +--rw ssh-key [name] 255 +--rw name string 256 +--rw algorithm? string 257 +--rw key-data? binary 259 3.5.1. SSH Public Key Authentication 261 If the NETCONF server advertises the "local-users" feature, 262 configuration of local users and their SSH public keys is supported 263 in the /system/authentication/user list. 265 Public key authentication is requested by the SSH client. If the 266 "local-users" feature is supported, then when a NETCONF client starts 267 an SSH session towards the server using the "publickey" 268 authentication "method name" [RFC4252], the SSH server looks up the 269 user name given in the SSH authentication request in the /system/ 270 authentication/user list, and verifies the key as described in 271 [RFC4253]. 273 3.5.2. Local User Password Authentication 275 If the NETCONF server advertises the "local-users" feature, 276 configuration of local users and their passwords is supported in the 277 /system/authentication/user list. 279 For NETCONF transport protocols that support password authentication, 280 the leaf-list "user-authentication-order" is used to control if local 281 user password authentication should be used. 283 In SSH, password authentication is requested by the client. Other 284 NETCONF transport protocols MAY also support password authentication. 286 When local user password authentication is requested, the NETCONF 287 transport looks up the user name provided by the client in the 288 /system/ authentication/user list, and verifies the password. 290 3.5.3. RADIUS Password Authentication 292 If the NETCONF server advertises the "radius-authentication" feature, 293 the device supports user authentication using RADIUS. 295 For NETCONF transport protocols that support password authentication, 296 the leaf-list "user-authentication-order" is used to control if 297 RADIUS password authentication should be used. 299 In SSH, password authentication is requested by the client. Other 300 NETCONF transport protocols MAY also support password authentication. 302 3.6. System Control 304 Two protocol operations are included to restart or shutdown the 305 system. The 'system-restart' operation can be used to restart the 306 entire system (not just the NETCONF server). The 'system-shutdown' 307 operation can be used to power off the entire system. 309 4. System YANG module 311 This YANG module imports YANG extensions from [RFC6536], and imports 312 YANG types from [RFC6021] and [I-D.lange-netmod-iana-timezones]. It 313 also references [RFC1321], [RFC2865], [RFC3418], [RFC5607], 314 [IEEE-1003.1-2008], and [FIPS.180-3.2008]. 316 RFC Ed.: update the date below with the date of RFC publication and 317 remove this note. 319 file "ietf-system@2012-07-11.yang" 321 module ietf-system { 322 namespace "urn:ietf:params:xml:ns:yang:ietf-system"; 323 prefix "sys"; 325 import ietf-yang-types { 326 prefix yang; 327 } 329 import ietf-inet-types { 330 prefix inet; 331 } 333 import ietf-netconf-acm { 334 prefix nacm; 335 } 337 import iana-timezones { 338 prefix ianatz; 339 } 341 organization 342 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 344 contact 345 "WG Web: 346 WG List: 348 WG Chair: David Kessens 349 351 WG Chair: Juergen Schoenwaelder 352 354 Editor: Andy Bierman 355 357 Editor: Martin Bjorklund 358 "; 360 description 361 "This module contains a collection of YANG definitions for the 362 configuration and identification of the management system of a 363 device. 365 Copyright (c) 2012 IETF Trust and the persons identified as 366 authors of the code. All rights reserved. 368 Redistribution and use in source and binary forms, with or 369 without modification, is permitted pursuant to, and subject 370 to the license terms contained in, the Simplified BSD License 371 set forth in Section 4.c of the IETF Trust's Legal Provisions 372 Relating to IETF Documents 373 (http://trustee.ietf.org/license-info). 375 This version of this YANG module is part of RFC XXXX; see 376 the RFC itself for full legal notices."; 378 // RFC Ed.: replace XXXX with actual RFC number and remove this 379 // note. 381 // RFC Ed.: remove this note 382 // Note: extracted from draft-ietf-netmod-system-mgmt-02.txt 384 // RFC Ed.: update the date below with the date of RFC publication 385 // and remove this note. 386 revision "2012-07-11" { 387 description 388 "Initial revision."; 389 reference 390 "RFC XXXX: A YANG Data Model for System Management"; 391 } 393 /* 394 * Typedefs 395 */ 397 typedef crypt-hash { 398 type string { 399 pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*"; 400 } 401 description 402 "The crypt-hash type is used to store passwords using 403 a hash function. This type is implemented in various UNIX 404 systems as the function crypt(3). 406 When a clear text value is set to a leaf of this type, the 407 server calculates a password hash, and stores the result 408 in the datastore. Thus, the password is never stored in 409 clear text. 411 When a leaf of this type is read, the stored password hash is 412 returned. 414 A value of this type matches one of the forms: 416 $0$ 417 $$$ 419 The '$0$' prefix signals that the value is clear text. When 420 such a value is received by the server, a hash value is 421 calculated, and the string '$$$' is prepended to the 422 result, where is a random 2-16 characters long salt 423 used to generate the digest. This value is stored in the 424 configuration data store. 426 If a value starting with '$$$' is received, the 427 server knows that the value already represents a hashed value, 428 and stores it as is in the data store. 430 When a server needs to verify a password given by a user, it 431 finds the stored password hash string for that user, extracts 432 the salt, and calculates the hash with the salt and given 433 password as input. If the calculated hash value is the same 434 as the stored value, the password given by the client is 435 correct. 437 This type defines the following hash functions: 439 id | hash function | feature 440 ---+---------------+------------------- 441 1 | MD5 | crypt-hash-md5 442 5 | SHA-256 | crypt-hash-sha-256 443 6 | SHA-512 | crypt-hash-sha-512 445 The server indicates support for the different hash functions 446 by advertising the corresponding feature."; 447 reference 448 "IEEE Std 1003.1-2008 - crypt() function 449 Wikipedia: http://en.wikipedia.org/wiki/Crypt_(Unix) 450 RFC 1321: The MD5 Message-Digest Algorithm 451 FIPS.180-3.2008: Secure Hash Standard"; 452 } 453 /* 454 * Features 455 */ 457 feature radius { 458 description 459 "Indicates that the device can be configured as a RADIUS 460 client."; 461 reference 462 "RFC 2865: Remote Authentication Dial In User Service " 463 + "(RADIUS)"; 464 } 466 feature authentication { 467 description 468 "Indicates that the device can be configured 469 to do authentication of users."; 470 } 472 feature local-users { 473 if-feature authentication; 474 description 475 "Indicates that the device supports 476 local user authentication."; 477 } 479 feature radius-authentication { 480 if-feature radius; 481 if-feature authentication; 482 description 483 "Indicates that the device supports user authentication over 484 RADIUS."; 485 reference 486 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 487 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 488 Authorization for Network Access Server (NAS) 489 Management"; 490 } 492 feature crypt-hash-md5 { 493 description 494 "Indicates that the device supports the MD5 495 hash function in 'crypt-hash' values"; 496 reference "RFC 1321: The MD5 Message-Digest Algorithm"; 497 } 499 feature crypt-hash-sha-256 { 500 description 501 "Indicates that the device supports the SHA-256 502 hash function in 'crypt-hash' values"; 503 reference "FIPS.180-3.2008: Secure Hash Standard"; 504 } 506 feature crypt-hash-sha-512 { 507 description 508 "Indicates that the device supports the SHA-512 509 hash function in 'crypt-hash' values"; 510 reference "FIPS.180-3.2008: Secure Hash Standard"; 511 } 513 feature ntp { 514 description 515 "Indicates that the device can be configured 516 to use one or more NTP servers to set the 517 system date and time."; 518 } 520 feature timezone-location { 521 description 522 "Indicates that the local timezone on the device 523 can be configured to use the TZ database 524 to set the timezone and manage daylight savings time."; 525 reference 526 "TZ Database http://www.twinsun.com/tz/tz-link.htm 527 Maintaining the Timezone Database 528 RFC 6557 (BCP 175)"; 529 } 531 /* 532 * Identities 533 */ 535 identity authentication-method { 536 description 537 "Base identity for user authentication methods."; 538 } 540 identity radius { 541 base authentication-method; 542 description 543 "Indicates user authentication using RADIUS."; 544 reference 545 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 546 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 547 Authorization for Network Access Server (NAS) 548 Management"; 550 } 552 identity local-users { 553 base authentication-method; 554 description 555 "Indicates password-based authentication of locally 556 configured users."; 557 } 559 identity configuration-source { 560 description "Base for all configuration sources."; 561 } 563 identity local-config { 564 base configuration-source; 565 description "Local configuration source."; 566 } 568 identity dhcp { 569 base configuration-source; 570 description "DHCP configuration source."; 571 } 573 /* 574 * Top-level container 575 */ 577 container system { 578 description 579 "System group configuration."; 581 leaf contact { 582 type string { 583 length "0..255"; 584 } 585 description 586 "The administrator contact information for the system."; 587 reference 588 "RFC 3418 - Management Information Base (MIB) for the 589 Simple Network Management Protocol (SNMP) 590 SNMPv2-MIB.sysContact"; 591 } 593 leaf name { 594 type string { 595 length "0..255"; 596 } 597 description 598 "The administratively assigned system name."; 599 reference 600 "RFC 3418 - Management Information Base (MIB) for the 601 Simple Network Management Protocol (SNMP) 602 SNMPv2-MIB.sysName"; 603 } 605 leaf location { 606 type string { 607 length "0..255"; 608 } 609 description 610 "The system location"; 611 reference 612 "RFC 3418 - Management Information Base (MIB) for the 613 Simple Network Management Protocol (SNMP) 614 SNMPv2-MIB.sysLocation"; 615 } 617 container platform { 618 config false; 619 description 620 "Contains vendor-specific information for 621 identifying the system platform and operating system."; 622 reference 623 "IEEE Std 1003.1-2008 - sys/utsname.h"; 625 leaf os-name { 626 type string; 627 description 628 "The name of the operating system in use, 629 for example 'Linux'"; 630 reference 631 "IEEE Std 1003.1-2008 - utsname.sysname"; 632 } 634 leaf os-release { 635 type string; 636 description 637 "The current release level of the operating 638 system in use. This string MAY indicate 639 the OS source code revision."; 640 reference 641 "IEEE Std 1003.1-2008 - utsname.release"; 642 } 643 leaf os-version { 644 type string; 645 description 646 "The current version level of the operating 647 system in use. This string MAY indicate 648 the specific OS build date and target variant 649 information."; 650 reference 651 "IEEE Std 1003.1-2008 - utsname.version"; 652 } 654 leaf machine { 655 type string; 656 description 657 "A vendor-specific identifier string representing 658 the hardware in use."; 659 reference 660 "IEEE Std 1003.1-2008 - utsname.machine"; 661 } 663 leaf nodename { 664 type string; 665 description 666 "The host name of this system."; 667 reference 668 "IEEE Std 1003.1-2008 - utsname.nodename"; 669 } 670 } 672 container clock { 673 description 674 "Configuration and monitoring of the system 675 date and time properties."; 677 leaf current-datetime { 678 type yang:date-and-time; 679 config false; 680 description 681 "The current system date and time."; 682 } 684 leaf boot-datetime { 685 type yang:date-and-time; 686 config false; 687 description 688 "The system date and time when the NETCONF 689 server last restarted."; 690 } 691 choice timezone { 692 description 693 "Configure the system timezone information."; 695 leaf timezone-location { 696 if-feature timezone-location; 697 type ianatz:iana-timezone; 698 description 699 "The TZ database location identifier string 700 to use for the system, such as 'Europe/Stockholm'."; 701 } 703 leaf timezone-utc-offset { 704 type int16 { 705 range "-1439 .. 1439"; 706 } 707 description 708 "The number of minutes to add to UTC time to 709 identify the timezone for this system. 710 For example, 'UTC - 8:00 hours' would be 711 represented as '-480'. Note that automatic 712 daylight savings time adjustment is not provided, 713 if this object is used."; 714 } 715 } 716 } 718 grouping configuration-source { 719 leaf-list configuration-source { 720 ordered-by user; 721 type identityref { 722 base configuration-source; 723 } 724 description 725 "Indicates the ordered list of configuration source(s) 726 that the server should use for the service."; 727 } 728 } 730 container ntp { 731 if-feature ntp; 733 description 734 "Configuration of the NTP client."; 736 leaf use-ntp { 737 type boolean; 738 default true; 739 description 740 "Indicates that the system should attempt 741 to synchronize the system clock with an 742 NTP server from the 'ntp-server' list."; 743 } 745 uses configuration-source; 747 list ntp-server { 748 key address; 749 description 750 "List of NTP servers to use for 751 system clock synchronization. If 'use-ntp' 752 is 'true', then the system will attempt to 753 contact and utilize the specified NTP servers."; 755 leaf association-type { 756 type enumeration { 757 enum server { 758 description 759 "Use server association mode. This device 760 is not expected to synchronize with the 761 configured NTP server."; 762 } 763 enum peer { 764 description 765 "Use peer association mode. This device 766 may be expected to synchronize with the 767 configured NTP server."; 768 } 769 enum pool { 770 description 771 "Use pool association mode. This device 772 is not expected to synchronize with the 773 configured NTP server."; 774 } 775 } 776 description 777 "The desired association type for this NTP server."; 778 default server; 779 } 780 leaf address { 781 type inet:host; 782 description 783 "The IP address or domain name of the NTP server."; 784 } 785 leaf enabled { 786 type boolean; 787 default true; 788 description 789 "Indicates whether this server is enabled for use or 790 not."; 791 } 792 leaf iburst { 793 type boolean; 794 default false; 795 description 796 "Indicates whether this server should enable burst 797 synchronization or not."; 798 } 799 leaf prefer { 800 type boolean; 801 default false; 802 description 803 "Indicates whether this server should be preferred 804 or not."; 805 } 806 } 807 } 809 container dns { 810 description 811 "Configuration of the DNS resolver."; 813 uses configuration-source; 815 leaf-list search { 816 type inet:host; 817 ordered-by user; 818 description 819 "An ordered list of domains to search when resolving 820 a host name."; 821 } 822 leaf-list server { 823 type inet:ip-address; 824 ordered-by user; 825 description 826 "Addresses of the name servers that the resolver should 827 query. 829 Implementations MAY limit the number of entries in this 830 leaf list."; 831 } 832 container options { 833 description 834 "Resolver options. The set of available options has been 835 limited to those that are generally available across 836 different resolver implementations, and generally 837 useful."; 838 leaf ndots { 839 type uint8; 840 default "1"; 841 description 842 "This parameter sets a threshold for the number of dots 843 which must appear in a query request before an initial 844 absolute query will be made."; 845 } 846 leaf timeout { 847 type uint8; 848 units "seconds"; 849 default "5"; 850 description 851 "The amount of time the resolver will wait for a 852 response from a remote name server before 853 retrying the query via a different name server."; 854 } 855 leaf attempts { 856 type uint8; 857 default "2"; 858 description 859 "The number of times the resolver will send a query to 860 its name servers before giving up and returning an 861 error to the calling application."; 862 } 863 } 864 } 866 container radius { 867 if-feature radius; 869 description 870 "Configuration of the RADIUS client."; 872 list server { 873 key address; 874 ordered-by user; 875 description 876 "List of RADIUS servers used by the device."; 878 leaf address { 879 type inet:host; 880 description 881 "The address of the RADIUS server."; 882 } 883 leaf authentication-port { 884 type inet:port-number; 885 default "1812"; 886 description 887 "The port number of the RADIUS server."; 888 } 889 leaf shared-secret { 890 type string; 891 nacm:default-deny-all; 892 description 893 "The shared secret which is known to both the RADIUS 894 client and server."; 895 reference 896 "RFC 2865: Remote Authentication Dial In User Service"; 897 } 898 } 899 container options { 900 description 901 "RADIUS client options."; 903 leaf timeout { 904 type uint8; 905 units "seconds"; 906 default "5"; 907 description 908 "The number of seconds the device will wait for a 909 response from a RADIUS server before trying with a 910 different server."; 911 } 912 leaf attempts { 913 type uint8; 914 default "2"; 915 description 916 "The number of times the device will send a query to 917 the RADIUS servers before giving up."; 918 } 919 } 920 } 922 container authentication { 923 nacm:default-deny-write; 924 if-feature authentication; 926 description 927 "The authentication configuration subtree."; 929 leaf-list user-authentication-order { 930 type identityref { 931 base authentication-method; 932 } 933 must '(. = "sys:radius" and ../../radius/server) or' 934 + '(. != "sys:radius")' { 935 error-message 936 "When 'radius' is used, a radius server" 937 + " must be configured."; 938 } 939 ordered-by user; 941 description 942 "When the device authenticates a user with 943 a password, it tries the authentication methods in this 944 leaf-list in order. If authentication with one method 945 fails, the next method is used. If no method succeeds, 946 the user is denied access. 948 If the 'radius-authentication' feature is advertised by 949 the NETCONF server, the 'radius' identity can be added to 950 this list. 952 If the 'local-users' feature is advertised by the 953 NETCONF server, the 'local-users' identity can be 954 added to this list."; 955 } 957 list user { 958 if-feature local-users; 959 key name; 960 description 961 "The list of local users configured on this device."; 963 leaf name { 964 type string; 965 description 966 "The user name string identifying this entry."; 967 } 968 leaf password { 969 type crypt-hash; 970 description 971 "The password for this entry."; 972 } 973 list ssh-key { 974 key name; 975 description 976 "A list of public SSH keys for this user."; 977 reference 978 "RFC 4253: The Secure Shell (SSH) Transport Layer 979 Protocol"; 981 leaf name { 982 type string; 983 description 984 "An arbitrary name for the ssh key."; 985 } 986 leaf algorithm { 987 type string; 988 description 989 "The public key algorithm name for this ssh key. 991 Valid values are the values in the IANA Secure Shell 992 (SSH) Protocol Parameters registry, Public Key 993 Algorithm Names"; 994 reference 995 "IANA Secure Shell (SSH) Protocol Parameters registry, 996 Public Key Algorithm Names"; 997 } 998 leaf key-data { 999 type binary; 1000 description 1001 "The binary key data for this ssh key."; 1002 } 1003 } 1004 } 1005 } 1006 } 1008 rpc set-current-datetime { 1009 nacm:default-deny-all; 1010 description 1011 "Manually set the /system/clock/current-datetime leaf 1012 to the specified value. 1014 If the system is using NTP (e.g., /system/ntp/use-ntp 1015 is set to 'true'), then this operation will 1016 fail with error-tag 'operation-failed', 1017 and error-app-tag value of 'ntp-active'"; 1018 input { 1019 leaf current-datetime { 1020 type yang:date-and-time; 1021 mandatory true; 1022 description 1023 "The current system date and time."; 1024 } 1025 } 1026 } 1027 rpc system-restart { 1028 nacm:default-deny-all; 1029 description 1030 "Request that the entire system be restarted immediately. 1031 A server SHOULD send an rpc reply to the client before 1032 restarting the system."; 1033 } 1035 rpc system-shutdown { 1036 nacm:default-deny-all; 1037 description 1038 "Request that the entire system be shut down immediately. 1039 A server SHOULD send an rpc reply to the client before 1040 shutting down the system."; 1041 } 1043 } 1045 1047 5. IANA Considerations 1049 This document registers a URI in the IETF XML registry [RFC3688]. 1050 Following the format in RFC 3688, the following registration is 1051 requested to be made. 1053 URI: urn:ietf:params:xml:ns:yang:ietf-system 1055 Registrant Contact: The NETMOD WG of the IETF. 1057 XML: N/A, the requested URI is an XML namespace. 1059 This document registers a YANG module in the YANG Module Names 1060 registry [RFC6020]. 1062 name: ietf-system 1063 namespace: urn:ietf:params:xml:ns:yang:ietf-system 1064 prefix: sys 1065 reference: RFC XXXX 1067 6. Security Considerations 1069 The YANG module defined in this memo is designed to be accessed via 1070 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1071 secure transport layer and the mandatory-to-implement secure 1072 transport is SSH [RFC6242]. 1074 There are a number of data nodes defined in this YANG module which 1075 are writable/creatable/deletable (i.e., config true, which is the 1076 default). These data nodes may be considered sensitive or vulnerable 1077 in some network environments. Write operations (e.g., edit-config) 1078 to these data nodes without proper protection can have a negative 1079 effect on network operations. These are the subtrees and data nodes 1080 and their sensitivity/vulnerability: 1082 o /system/clock/timezone: This choice contains the objects used to 1083 control the timezone used by the device. 1085 o /system/ntp: This container contains the objects used to control 1086 the Network Time Protocol servers used by the device. 1088 o /system/dns: This container contains the objects used to control 1089 the Domain Name System servers used by the device. 1091 o /system/radius: This container contains the objects used to 1092 control the Remote Authentication Dial-In User Service servers 1093 used by the device. 1095 o /system/authentication/user-authentication-order: This leaf 1096 controls how user login attempts are authenticated by the device. 1098 o /system/authentication/user: This list contains the local users 1099 enabled on the system. 1101 Some of the readable data nodes in this YANG module may be considered 1102 sensitive or vulnerable in some network environments. It is thus 1103 important to control read access (e.g., via get, get-config, or 1104 notification) to these data nodes. These are the subtrees and data 1105 nodes and their sensitivity/vulnerability: 1107 o /system/platform: This container has objects which may help 1108 identify the specific NETCONF server and/or operating system 1109 implementation used on the device. 1111 Some of the RPC operations in this YANG module may be considered 1112 sensitive or vulnerable in some network environments. It is thus 1113 important to control access to these operations. These are the 1114 operations and their sensitivity/vulnerability: 1116 o set-current-datetime: Changes the current date and time on the 1117 device. 1119 o system-restart: Reboots the device. 1121 o system-shutdown: Shuts down the device. 1123 7. Change Log 1125 -- RFC Ed.: remove this section before publication. 1127 7.1. 00-01 1129 o added configuration-source identities 1131 o added configuration-source leaf to ntp and dns (via grouping) to 1132 choose configuration source 1134 o added association-type, iburst, prefer, and true leafs to the ntp- 1135 server list 1137 o extended the ssh keys for a user to a list of keys. support all 1138 defined key algorithms, not just dsa and rsa 1140 o clarified timezone-utc-offset description-stmt 1142 o removed '/system/ntp/server/true' leaf from data model 1144 7.2. 01-02 1146 o added default-stmts to ntp-server/iburst and ntp-server/prefer 1147 leafs 1149 o changed timezone-location leaf to use iana-timezone typedef 1150 instead of a string 1152 8. Normative References 1154 [FIPS.180-3.2008] 1155 National Institute of Standards and Technology, "Secure 1156 Hash Standard", FIPS PUB 180-3, October 2008, . 1160 [I-D.lange-netmod-iana-timezones] 1161 Lange, J., "IANA Timezone Database YANG Modul", 1162 draft-lange-netmod-iana-timezones-01 (work in progress), 1163 June 2012. 1165 [IEEE-1003.1-2008] 1166 Institute of Electrical and Electronics Engineers, 1167 "POSIX.1-2008", IEEE Standard 1003.1, March 2008. 1169 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1170 April 1992. 1172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1173 Requirement Levels", BCP 14, RFC 2119, March 1997. 1175 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1176 "Remote Authentication Dial In User Service (RADIUS)", 1177 RFC 2865, June 2000. 1179 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1180 Simple Network Management Protocol (SNMP)", STD 62, 1181 RFC 3418, December 2002. 1183 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1184 January 2004. 1186 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1187 Authentication Protocol", RFC 4252, January 2006. 1189 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1190 Transport Layer Protocol", RFC 4253, January 2006. 1192 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 1193 User Service (RADIUS) Authorization for Network Access 1194 Server (NAS) Management", RFC 5607, July 2009. 1196 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1197 Network Configuration Protocol (NETCONF)", RFC 6020, 1198 October 2010. 1200 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 1201 October 2010. 1203 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1204 and A. Bierman, Ed., "Network Configuration Protocol 1205 (NETCONF)", RFC 6241, June 2011. 1207 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1208 Shell (SSH)", RFC 6242, June 2011. 1210 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1211 Protocol (NETCONF) Access Control Model", RFC 6536, 1212 March 2012. 1214 [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the 1215 Time Zone Database", BCP 175, RFC 6557, February 2012. 1217 Authors' Addresses 1219 Andy Bierman 1220 YumaWorks 1222 Email: andy@yumaworks.com 1224 Martin Bjorklund 1225 Tail-f Systems 1227 Email: mbj@tail-f.com