idnits 2.17.1 draft-ietf-netmod-system-mgmt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 186 has weird spacing: '...address ine...' == Line 187 has weird spacing: '...enabled boo...' == Line 520 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 30, 2012) is 4318 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) -- 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: 3 errors (**), 0 flaws (~~), 5 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 1, 2013 Tail-f Systems 6 June 30, 2012 8 YANG Data Model for System Management 9 draft-ietf-netmod-system-mgmt-01 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 1, 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 8. Normative References . . . . . . . . . . . . . . . . . . . . . 29 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 75 1. Introduction 77 This document defines a YANG [RFC6020] data model for the 78 configuration and identification of the management system of a 79 device. 81 Devices that are managed by NETCONF and perhaps other mechanisms have 82 common properties that need to be configured and monitored in a 83 standard way. 85 The YANG module defined in this document provides the following 86 features: 88 o system administrative data configuration 90 o system identification monitoring 92 o system time-of-day configuration and monitoring 94 o user authentication configuration 96 o local users configuration 98 1.1. Terminology 100 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14, [RFC2119]. 105 1.1.1. Terms 107 The following terms are used within this document: 109 o system: This term refers to the embodiment of the entire set of 110 management interfaces that a single NETCONF server is supporting 111 at a given moment. The set of physical entities managed by a 112 single NETCONF server can be static or it can change dynamically. 114 2. Objectives 116 2.1. System Identification 118 There are many common properties used to identify devices, operating 119 systems, software versions, etc. that need to be supported in the 120 system data module. These objects are defined as operational data 121 and intended to be specific to the device vendor. 123 Some user-configurable administrative strings are also provided such 124 as the system location and description. 126 2.2. System Time Management 128 The management of the date and time used by the system need to be 129 supported. Use of one or more NTP servers to automatically set the 130 system date and time need to be possible. Utilization of the 131 Timezone database [RFC6557] also need to be supported. 133 2.3. User Authentication 135 The authentication mechanism need to support password authentication 136 over RADIUS, to support deployment scenarios with centralized 137 authentication servers. Additionally, local users need to be 138 supported, for scenarios when no centralized authentication server 139 exists, or for situations where the centralized authentication server 140 cannot be reached from the device. 142 Since the mandatory transport protocol for NETCONF is SSH [RFC6242] 143 the authentication model need to support SSH's "publickey" and 144 "password" authentication methods [RFC4252]. 146 The model for authentication configuration should be flexible enough 147 to support authentication methods defined by other standard documents 148 or by vendors. 150 3. System Data Model 152 3.1. System Identification 154 The data model for system identification has the following structure: 156 +--rw system 157 +--rw contact? string 158 +--rw name? string 159 +--rw location? string 160 +--ro platform 161 +--ro os-name? string 162 +--ro os-release? string 163 +--ro os-version? string 164 +--ro machine? string 165 +--ro nodename? string 167 3.2. System Time Management 169 The data model for system time management has the following 170 structure: 172 +--rw system 173 +--rw clock 174 | +--ro current-datetime? yang:date-and-time 175 | +--ro boot-datetime? yang:date-and-time 176 | +--rw (timezone)? 177 | +--:(timezone-location) 178 | | +--rw timezone-location? string 179 | +--:(timezone-utc-offset) 180 | +--rw timezone-utc-offset? int16 181 +--rw ntp 182 +--rw use-ntp? boolean 183 +--rw configuration-source* identityref 184 +--rw ntp-server [address] 185 +--rw association-type? enumeration 186 +--rw address inet:host 187 +--rw enabled boolean 188 +--rw iburst boolean 189 +--rw prefer boolean 191 3.3. DNS Resolver Model 193 The data model for configuration of the DNS resolver has the 194 following structure: 196 +--rw system 197 +--rw dns 198 +--rw configuration-source* identityref 199 +--rw search* inet:host 200 +--rw server* inet:ip-address 201 +--rw options 202 +--rw ndots? uint8 203 +--rw timeout? uint8 204 +--rw attempts? uint8 206 3.4. RADIUS Client Model 208 The data model for configuration of the RADIUS client has the 209 following structure: 211 +--rw system 212 +--rw radius 213 +--rw server [address] 214 | +--rw address inet:host 215 | +--rw authentication-port? inet:port-number 216 | +--rw shared-secret? string 217 +--rw options 218 +--rw timeout? uint8 219 +--rw attempts? uint8 221 3.5. User Authentication Model 223 This document defines three authentication methods for use with 224 NETCONF: 226 o publickey for local users over SSH 228 o password for local users over any transport 230 o password for RADIUS users over any transport 232 Additional methods can be defined by other standard documents or by 233 vendors. 235 This document defines two optional YANG features, "local-users" and 236 "radius-authentication", which the server advertises to indicate 237 support for configuring local users on the device, and support for 238 using RADIUS for authentication, respectively. 240 The authentication parameters defined in this document are primarily 241 used to configure authentication of NETCONF users, but MAY also be 242 used by other interfaces, e.g., a Command Line Interface or a Web- 243 based User Interface. 245 The data model for user authentication has the following structure: 247 +--rw system 248 +--rw authentication 249 +--rw user-authentication-order* identityref 250 +--rw user [name] 251 +--rw name string 252 +--rw password? crypt-hash 253 +--rw ssh-key [name] 254 +--rw name string 255 +--rw algorithm? string 256 +--rw key-data? binary 258 3.5.1. SSH Public Key Authentication 260 If the NETCONF server advertises the "local-users" feature, 261 configuration of local users and their SSH public keys is supported 262 in the /system/authentication/user list. 264 Public key authentication is requested by the SSH client. If the 265 "local-users" feature is supported, then when a NETCONF client starts 266 an SSH session towards the server using the "publickey" 267 authentication "method name" [RFC4252], the SSH server looks up the 268 user name given in the SSH authentication request in the /system/ 269 authentication/user list, and verifies the key as described in 270 [RFC4253]. 272 3.5.2. Local User Password Authentication 274 If the NETCONF server advertises the "local-users" feature, 275 configuration of local users and their passwords is supported in the 276 /system/authentication/user list. 278 For NETCONF transport protocols that support password authentication, 279 the leaf-list "user-authentication-order" is used to control if local 280 user password authentication should be used. 282 In SSH, password authentication is requested by the client. Other 283 NETCONF transport protocols MAY also support password authentication. 285 When local user password authentication is requested, the NETCONF 286 transport looks up the user name provided by the client in the 287 /system/ authentication/user list, and verifies the password. 289 3.5.3. RADIUS Password Authentication 291 If the NETCONF server advertises the "radius-authentication" feature, 292 the device supports user authentication using RADIUS. 294 For NETCONF transport protocols that support password authentication, 295 the leaf-list "user-authentication-order" is used to control if 296 RADIUS password authentication should be used. 298 In SSH, password authentication is requested by the client. Other 299 NETCONF transport protocols MAY also support password authentication. 301 3.6. System Control 303 Two protocol operations are included to restart or shutdown the 304 system. The 'system-restart' operation can be used to restart the 305 entire system (not just the NETCONF server). The 'system-shutdown' 306 operation can be used to power off the entire system. 308 4. System YANG module 310 This YANG module imports YANG extensions from [RFC6536], imports YANG 311 types from [RFC6021], and references [RFC1321], [RFC2865], [RFC3418], 312 [RFC5607], [IEEE-1003.1-2008], and [FIPS.180-3.2008]. 314 RFC Ed.: update the date below with the date of RFC publication and 315 remove this note. 317 file "ietf-system@2012-06-30.yang" 319 module ietf-system { 320 namespace "urn:ietf:params:xml:ns:yang:ietf-system"; 321 prefix "sys"; 323 import ietf-yang-types { 324 prefix yang; 325 } 327 import ietf-inet-types { 328 prefix inet; 329 } 331 import ietf-netconf-acm { 332 prefix nacm; 333 } 335 organization 336 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 338 contact 339 "WG Web: 340 WG List: 342 WG Chair: David Kessens 343 345 WG Chair: Juergen Schoenwaelder 346 348 Editor: Andy Bierman 349 351 Editor: Martin Bjorklund 352 "; 354 description 355 "This module contains a collection of YANG definitions for the 356 configuration and identification of the management system of a 357 device. 359 Copyright (c) 2012 IETF Trust and the persons identified as 360 authors of the code. All rights reserved. 362 Redistribution and use in source and binary forms, with or 363 without modification, is permitted pursuant to, and subject 364 to the license terms contained in, the Simplified BSD License 365 set forth in Section 4.c of the IETF Trust's Legal Provisions 366 Relating to IETF Documents 367 (http://trustee.ietf.org/license-info). 369 This version of this YANG module is part of RFC XXXX; see 370 the RFC itself for full legal notices."; 372 // RFC Ed.: replace XXXX with actual RFC number and remove this 373 // note. 375 // RFC Ed.: remove this note 376 // Note: extracted from draft-ietf-netmod-system-mgmt-01.txt 378 // RFC Ed.: update the date below with the date of RFC publication 379 // and remove this note. 380 revision "2012-06-30" { 381 description 382 "Initial revision."; 383 reference 384 "RFC XXXX: A YANG Data Model for System Management"; 385 } 387 /* 388 * Typedefs 389 */ 391 typedef crypt-hash { 392 type string { 393 pattern "$0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.*"; 394 } 395 description 396 "The crypt-hash type is used to store passwords using 397 a hash function. This type is implemented in various UNIX 398 systems as the function crypt(3). 400 When a clear text value is set to a leaf of this type, the 401 server calculates a password hash, and stores the result 402 in the datastore. Thus, the password is never stored in 403 clear text. 405 When a leaf of this type is read, the stored password hash is 406 returned. 408 A value of this type matches one of the forms: 410 $0$ 411 $$$ 413 The '$0$' prefix signals that the value is clear text. When 414 such a value is received by the server, a hash value is 415 calculated, and the string '$$$' is prepended to the 416 result, where is a random 2-16 characters long salt 417 used to generate the digest. This value is stored in the 418 configuration data store. 420 If a value starting with '$$$' is received, the 421 server knows that the value already represents a hashed value, 422 and stores it as is in the data store. 424 When a server needs to verify a password given by a user, it 425 finds the stored password hash string for that user, extracts 426 the salt, and calculates the hash with the salt and given 427 password as input. If the calculated hash value is the same 428 as the stored value, the password given by the client is 429 correct. 431 This type defines the following hash functions: 433 id | hash function | feature 434 ---+---------------+------------------- 435 1 | MD5 | crypt-hash-md5 436 5 | SHA-256 | crypt-hash-sha-256 437 6 | SHA-512 | crypt-hash-sha-512 439 The server indicates support for the different hash functions 440 by advertising the corresponding feature."; 441 reference 442 "IEEE Std 1003.1-2008 - crypt() function 443 Wikipedia: http://en.wikipedia.org/wiki/Crypt_(Unix) 444 RFC 1321: The MD5 Message-Digest Algorithm 445 FIPS.180-3.2008: Secure Hash Standard"; 446 } 448 /* 449 * Features 450 */ 452 feature radius { 453 description 454 "Indicates that the device can be configured as a RADIUS 455 client."; 456 reference 457 "RFC 2865: Remote Authentication Dial In User Service " 458 + "(RADIUS)"; 459 } 461 feature authentication { 462 description 463 "Indicates that the device can be configured 464 to do authentication of users."; 465 } 467 feature local-users { 468 if-feature authentication; 469 description 470 "Indicates that the device supports 471 local user authentication."; 472 } 474 feature radius-authentication { 475 if-feature radius; 476 if-feature authentication; 477 description 478 "Indicates that the device supports user authentication over 479 RADIUS."; 480 reference 481 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 482 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 483 Authorization for Network Access Server (NAS) 484 Management"; 485 } 487 feature crypt-hash-md5 { 488 description 489 "Indicates that the device supports the MD5 490 hash function in 'crypt-hash' values"; 491 reference "RFC 1321: The MD5 Message-Digest Algorithm"; 492 } 494 feature crypt-hash-sha-256 { 495 description 496 "Indicates that the device supports the SHA-256 497 hash function in 'crypt-hash' values"; 498 reference "FIPS.180-3.2008: Secure Hash Standard"; 499 } 500 feature crypt-hash-sha-512 { 501 description 502 "Indicates that the device supports the SHA-512 503 hash function in 'crypt-hash' values"; 504 reference "FIPS.180-3.2008: Secure Hash Standard"; 505 } 507 feature ntp { 508 description 509 "Indicates that the device can be configured 510 to use one or more NTP servers to set the 511 system date and time."; 512 } 514 feature timezone-location { 515 description 516 "Indicates that the local timezone on the device 517 can be configured to use the TZ database 518 to set the timezone and manage daylight savings time."; 519 reference 520 "TZ Database http://www.twinsun.com/tz/tz-link.htm 521 Maintaining the Timezone Database 522 RFC 6557 (BCP 175)"; 523 } 525 /* 526 * Identities 527 */ 529 identity authentication-method { 530 description 531 "Base identity for user authentication methods."; 532 } 534 identity radius { 535 base authentication-method; 536 description 537 "Indicates user authentication using RADIUS."; 538 reference 539 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 540 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 541 Authorization for Network Access Server (NAS) 542 Management"; 543 } 545 identity local-users { 546 base authentication-method; 547 description 548 "Indicates password-based authentication of locally 549 configured users."; 550 } 552 identity configuration-source { 553 description "Base for all configuration sources."; 554 } 556 identity local-config { 557 base configuration-source; 558 description "Local configuration source."; 559 } 561 identity dhcp { 562 base configuration-source; 563 description "DHCP configuration source."; 564 } 566 /* 567 * Top-level container 568 */ 570 container system { 571 description 572 "System group configuration."; 574 leaf contact { 575 type string { 576 length "0..255"; 577 } 578 description 579 "The administrator contact information for the system."; 580 reference 581 "RFC 3418 - Management Information Base (MIB) for the 582 Simple Network Management Protocol (SNMP) 583 SNMPv2-MIB.sysContact"; 584 } 586 leaf name { 587 type string { 588 length "0..255"; 589 } 590 description 591 "The administratively assigned system name."; 592 reference 593 "RFC 3418 - Management Information Base (MIB) for the 594 Simple Network Management Protocol (SNMP) 595 SNMPv2-MIB.sysName"; 596 } 598 leaf location { 599 type string { 600 length "0..255"; 601 } 602 description 603 "The system location"; 604 reference 605 "RFC 3418 - Management Information Base (MIB) for the 606 Simple Network Management Protocol (SNMP) 607 SNMPv2-MIB.sysLocation"; 608 } 610 container platform { 611 config false; 612 description 613 "Contains vendor-specific information for 614 identifying the system platform and operating system."; 615 reference 616 "IEEE Std 1003.1-2008 - sys/utsname.h"; 618 leaf os-name { 619 type string; 620 description 621 "The name of the operating system in use, 622 for example 'Linux'"; 623 reference 624 "IEEE Std 1003.1-2008 - utsname.sysname"; 625 } 627 leaf os-release { 628 type string; 629 description 630 "The current release level of the operating 631 system in use. This string MAY indicate 632 the OS source code revision."; 633 reference 634 "IEEE Std 1003.1-2008 - utsname.release"; 635 } 637 leaf os-version { 638 type string; 639 description 640 "The current version level of the operating 641 system in use. This string MAY indicate 642 the specific OS build date and target variant 643 information."; 644 reference 645 "IEEE Std 1003.1-2008 - utsname.version"; 646 } 648 leaf machine { 649 type string; 650 description 651 "A vendor-specific identifier string representing 652 the hardware in use."; 653 reference 654 "IEEE Std 1003.1-2008 - utsname.machine"; 655 } 657 leaf nodename { 658 type string; 659 description 660 "The host name of this system."; 661 reference 662 "IEEE Std 1003.1-2008 - utsname.nodename"; 663 } 664 } 666 container clock { 667 description 668 "Configuration and monitoring of the system 669 date and time properties."; 671 leaf current-datetime { 672 type yang:date-and-time; 673 config false; 674 description 675 "The current system date and time."; 676 } 678 leaf boot-datetime { 679 type yang:date-and-time; 680 config false; 681 description 682 "The system date and time when the NETCONF 683 server last restarted."; 684 } 686 choice timezone { 687 description 688 "Configure the system timezone information."; 690 leaf timezone-location { 691 if-feature timezone-location; 692 type string; 693 description 694 "The TZ database location identifier string 695 to use for the system, such as 'Europe/Stockholm'. 696 [FIXME: replace string with enumeration]"; 697 } 699 leaf timezone-utc-offset { 700 type int16 { 701 range "-1439 .. 1439"; 702 } 703 description 704 "The number of minutes to add to UTC time to 705 identify the timezone for this system. 706 For example, 'UTC - 8:00 hours' would be 707 represented as '-480'. Note that automatic 708 daylight savings time adjustment is not provided, 709 if this object is used."; 710 } 711 } 712 } 714 grouping configuration-source { 715 leaf-list configuration-source { 716 ordered-by user; 717 type identityref { 718 base configuration-source; 719 } 720 description 721 "Indicates the ordered list of configuration source(s) 722 that the server should use for the service."; 723 } 724 } 726 container ntp { 727 if-feature ntp; 729 description 730 "Configuration of the NTP client."; 732 leaf use-ntp { 733 type boolean; 734 default true; 735 description 736 "Indicates that the system should attempt 737 to synchronize the system clock with an 738 NTP server from the 'ntp-server' list."; 739 } 741 uses configuration-source; 743 list ntp-server { 744 key address; 745 description 746 "List of NTP servers to use for 747 system clock synchronization. If 'use-ntp' 748 is 'true', then the system will attempt to 749 contact and utilize the specified NTP servers."; 751 leaf association-type { 752 type enumeration { 753 enum server { 754 description 755 "Use server association mode. This device 756 is not expected to synchronize with the 757 configured NTP server."; 758 } 759 enum peer { 760 description 761 "Use peer association mode. This device 762 may be expected to synchronize with the 763 configured NTP server."; 764 } 765 enum pool { 766 description 767 "Use pool association mode. This device 768 is not expected to synchronize with the 769 configured NTP server."; 770 } 771 } 772 description 773 "The desired association type for this NTP server."; 774 default server; 775 } 776 leaf address { 777 type inet:host; 778 description 779 "The IP address or domain name of the NTP server."; 780 } 781 leaf enabled { 782 type boolean; 783 default true; 784 description 785 "Indicates whether this server is enabled for use or 786 not."; 787 } 788 leaf iburst { 789 type boolean; 790 description 791 "Indicates whether this server should enable burst 792 synchronization or not."; 793 } 794 leaf prefer { 795 type boolean; 796 description 797 "Indicates whether this server should be preferred 798 or not."; 799 } 800 } 801 } 803 container dns { 804 description 805 "Configuration of the DNS resolver."; 807 uses configuration-source; 809 leaf-list search { 810 type inet:host; 811 ordered-by user; 812 description 813 "An ordered list of domains to search when resolving 814 a host name."; 815 } 816 leaf-list server { 817 type inet:ip-address; 818 ordered-by user; 819 description 820 "Addresses of the name servers that the resolver should 821 query. 823 Implementations MAY limit the number of entries in this 824 leaf list."; 825 } 826 container options { 827 description 828 "Resolver options. The set of available options has been 829 limited to those that are generally available across 830 different resolver implementations, and generally 831 useful."; 832 leaf ndots { 833 type uint8; 834 default "1"; 835 description 836 "This parameter sets a threshold for the number of dots 837 which must appear in a query request before an initial 838 absolute query will be made."; 839 } 840 leaf timeout { 841 type uint8; 842 units "seconds"; 843 default "5"; 844 description 845 "The amount of time the resolver will wait for a 846 response from a remote name server before 847 retrying the query via a different name server."; 848 } 849 leaf attempts { 850 type uint8; 851 default "2"; 852 description 853 "The number of times the resolver will send a query to 854 its name servers before giving up and returning an 855 error to the calling application."; 856 } 857 } 858 } 860 container radius { 861 if-feature radius; 863 description 864 "Configuration of the RADIUS client."; 866 list server { 867 key address; 868 ordered-by user; 869 description 870 "List of RADIUS servers used by the device."; 872 leaf address { 873 type inet:host; 874 description 875 "The address of the RADIUS server."; 876 } 877 leaf authentication-port { 878 type inet:port-number; 879 default "1812"; 880 description 881 "The port number of the RADIUS server."; 883 } 884 leaf shared-secret { 885 type string; 886 nacm:default-deny-all; 887 description 888 "The shared secret which is known to both the RADIUS 889 client and server."; 890 reference 891 "RFC 2865: Remote Authentication Dial In User Service"; 892 } 893 } 894 container options { 895 description 896 "RADIUS client options."; 898 leaf timeout { 899 type uint8; 900 units "seconds"; 901 default "5"; 902 description 903 "The number of seconds the device will wait for a 904 response from a RADIUS server before trying with a 905 different server."; 906 } 907 leaf attempts { 908 type uint8; 909 default "2"; 910 description 911 "The number of times the device will send a query to 912 the RADIUS servers before giving up."; 913 } 914 } 915 } 917 container authentication { 918 nacm:default-deny-write; 919 if-feature authentication; 921 description 922 "The authentication configuration subtree."; 924 leaf-list user-authentication-order { 925 type identityref { 926 base authentication-method; 927 } 928 must '(. = "sys:radius" and ../../radius/server) or' 929 + '(. != "sys:radius")' { 930 error-message 931 "When 'radius' is used, a radius server" 932 + " must be configured."; 933 } 934 ordered-by user; 936 description 937 "When the device authenticates a user with 938 a password, it tries the authentication methods in this 939 leaf-list in order. If authentication with one method 940 fails, the next method is used. If no method succeeds, 941 the user is denied access. 943 If the 'radius-authentication' feature is advertised by 944 the NETCONF server, the 'radius' identity can be added to 945 this list. 947 If the 'local-users' feature is advertised by the 948 NETCONF server, the 'local-users' identity can be 949 added to this list."; 950 } 952 list user { 953 if-feature local-users; 954 key name; 955 description 956 "The list of local users configured on this device."; 958 leaf name { 959 type string; 960 description 961 "The user name string identifying this entry."; 962 } 963 leaf password { 964 type crypt-hash; 965 description 966 "The password for this entry."; 967 } 968 list ssh-key { 969 key name; 970 description 971 "A list of public SSH keys for this user."; 972 reference 973 "RFC 4253: The Secure Shell (SSH) Transport Layer 974 Protocol"; 976 leaf name { 977 type string; 978 description 979 "An arbitrary name for the ssh key."; 980 } 981 leaf algorithm { 982 type string; 983 description 984 "The public key algorithm name for this ssh key. 986 Valid values are the values in the IANA Secure Shell 987 (SSH) Protocol Parameters registry, Public Key 988 Algorithm Names"; 989 reference 990 "IANA Secure Shell (SSH) Protocol Parameters registry, 991 Public Key Algorithm Names"; 992 } 993 leaf key-data { 994 type binary; 995 description 996 "The binary key data for this ssh key."; 997 } 998 } 999 } 1000 } 1001 } 1003 rpc set-current-datetime { 1004 nacm:default-deny-all; 1005 description 1006 "Manually set the /system/clock/current-datetime leaf 1007 to the specified value. 1009 If the system is using NTP (e.g., /system/ntp/use-ntp 1010 is set to 'true'), then this operation will 1011 fail with error-tag 'operation-failed', 1012 and error-app-tag value of 'ntp-active'"; 1013 input { 1014 leaf current-datetime { 1015 type yang:date-and-time; 1016 mandatory true; 1017 description 1018 "The current system date and time."; 1019 } 1020 } 1021 } 1023 rpc system-restart { 1024 nacm:default-deny-all; 1025 description 1026 "Request that the entire system be restarted immediately. 1028 A server SHOULD send an rpc reply to the client before 1029 restarting the system."; 1030 } 1032 rpc system-shutdown { 1033 nacm:default-deny-all; 1034 description 1035 "Request that the entire system be shut down immediately. 1036 A server SHOULD send an rpc reply to the client before 1037 shutting down the system."; 1038 } 1040 } 1042 1044 5. IANA Considerations 1046 This document registers a URI in the IETF XML registry [RFC3688]. 1047 Following the format in RFC 3688, the following registration is 1048 requested to be made. 1050 URI: urn:ietf:params:xml:ns:yang:ietf-system 1052 Registrant Contact: The NETMOD WG of the IETF. 1054 XML: N/A, the requested URI is an XML namespace. 1056 This document registers a YANG module in the YANG Module Names 1057 registry [RFC6020]. 1059 name: ietf-system 1060 namespace: urn:ietf:params:xml:ns:yang:ietf-system 1061 prefix: sys 1062 reference: RFC XXXX 1064 6. Security Considerations 1066 The YANG module defined in this memo is designed to be accessed via 1067 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1068 secure transport layer and the mandatory-to-implement secure 1069 transport is SSH [RFC6242]. 1071 There are a number of data nodes defined in this YANG module which 1072 are writable/creatable/deletable (i.e., config true, which is the 1073 default). These data nodes may be considered sensitive or vulnerable 1074 in some network environments. Write operations (e.g., edit-config) 1075 to these data nodes without proper protection can have a negative 1076 effect on network operations. These are the subtrees and data nodes 1077 and their sensitivity/vulnerability: 1079 o /system/clock/timezone: This choice contains the objects used to 1080 control the timezone used by the device. 1082 o /system/ntp: This container contains the objects used to control 1083 the Network Time Protocol servers used by the device. 1085 o /system/dns: This container contains the objects used to control 1086 the Domain Name System servers used by the device. 1088 o /system/radius: This container contains the objects used to 1089 control the Remote Authentication Dial-In User Service servers 1090 used by the device. 1092 o /system/authentication/user-authentication-order: This leaf 1093 controls how user login attempts are authenticated by the device. 1095 o /system/authentication/user: This list contains the local users 1096 enabled on the system. 1098 Some of the readable data nodes in this YANG module may be considered 1099 sensitive or vulnerable in some network environments. It is thus 1100 important to control read access (e.g., via get, get-config, or 1101 notification) to these data nodes. These are the subtrees and data 1102 nodes and their sensitivity/vulnerability: 1104 o /system/platform: This container has objects which may help 1105 identify the specific NETCONF server and/or operating system 1106 implementation used on the device. 1108 Some of the RPC operations in this YANG module may be considered 1109 sensitive or vulnerable in some network environments. It is thus 1110 important to control access to these operations. These are the 1111 operations and their sensitivity/vulnerability: 1113 o set-current-datetime: Changes the current date and time on the 1114 device. 1116 o system-restart: Reboots the device. 1118 o system-shutdown: Shuts down the device. 1120 7. Change Log 1122 -- RFC Ed.: remove this section before publication. 1124 7.1. 00-01 1126 o added configuration-source identities 1128 o added configuration-source leaf to ntp and dns (via grouping) to 1129 choose configuration source 1131 o added association-type, iburst, prefer, and true leafs to the ntp- 1132 server list 1134 o extended the ssh keys for a user to a list of keys. support all 1135 defined key algorithms, not just dsa and rsa 1137 o clarified timezone-utc-offset description-stmt 1139 o removed '/system/ntp/server/true' leaf from data model 1141 8. Normative References 1143 [FIPS.180-3.2008] 1144 National Institute of Standards and Technology, "Secure 1145 Hash Standard", FIPS PUB 180-3, October 2008, . 1149 [IEEE-1003.1-2008] 1150 Institute of Electrical and Electronics Engineers, 1151 "POSIX.1-2008", IEEE Standard 1003.1, March 2008. 1153 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1154 April 1992. 1156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1157 Requirement Levels", BCP 14, RFC 2119, March 1997. 1159 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1160 "Remote Authentication Dial In User Service (RADIUS)", 1161 RFC 2865, June 2000. 1163 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1164 Simple Network Management Protocol (SNMP)", STD 62, 1165 RFC 3418, December 2002. 1167 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1168 January 2004. 1170 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1171 Authentication Protocol", RFC 4252, January 2006. 1173 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1174 Transport Layer Protocol", RFC 4253, January 2006. 1176 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 1177 User Service (RADIUS) Authorization for Network Access 1178 Server (NAS) Management", RFC 5607, July 2009. 1180 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1181 Network Configuration Protocol (NETCONF)", RFC 6020, 1182 October 2010. 1184 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 1185 October 2010. 1187 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1188 and A. Bierman, Ed., "Network Configuration Protocol 1189 (NETCONF)", RFC 6241, June 2011. 1191 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1192 Shell (SSH)", RFC 6242, June 2011. 1194 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1195 Protocol (NETCONF) Access Control Model", RFC 6536, 1196 March 2012. 1198 [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the 1199 Time Zone Database", BCP 175, RFC 6557, February 2012. 1201 Authors' Addresses 1203 Andy Bierman 1204 YumaWorks 1206 Email: andy@yumaworks.com 1208 Martin Bjorklund 1209 Tail-f Systems 1211 Email: mbj@tail-f.com