idnits 2.17.1 draft-ietf-netmod-system-mgmt-10.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 232 has weird spacing: '...address ine...' == Line 254 has weird spacing: '...rw name str...' == Line 258 has weird spacing: '...address ine...' == Line 324 has weird spacing: '...gorithm str...' == Line 630 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 (December 23, 2013) is 3771 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-1003.1-2008' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 5966 (Obsoleted by RFC 7766) ** Downref: Normative reference to an Informational RFC: RFC 6151 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 4 errors (**), 0 flaws (~~), 8 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: June 26, 2014 Tail-f Systems 6 December 23, 2013 8 A YANG Data Model for System Management 9 draft-ietf-netmod-system-mgmt-10 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 June 26, 2014. 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 . . . . . . . . . . . . . . . . . . . . 8 67 3.4. RADIUS Client Model . . . . . . . . . . . . . . . . . . . 8 68 3.5. User Authentication Model . . . . . . . . . . . . . . . . 9 69 3.5.1. SSH Public Key Authentication . . . . . . . . . . . . 9 70 3.5.2. Local User Password Authentication . . . . . . . . . . 10 71 3.5.3. RADIUS Password Authentication . . . . . . . . . . . . 10 72 3.6. System Control . . . . . . . . . . . . . . . . . . . . . . 10 73 4. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . . . 11 74 5. System YANG module . . . . . . . . . . . . . . . . . . . . . . 12 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 77 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 34 78 8.1. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 79 8.2. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 80 8.3. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 81 8.4. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 82 8.5. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 83 8.6. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 84 8.7. 06-07 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 85 8.8. 07-08 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 86 8.9. 08-09 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 87 8.10. 09-10 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 37 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 38 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 93 1. Introduction 95 This document defines a YANG [RFC6020] data model for the 96 configuration and identification of some common properties within a 97 device containing a NETCONF server. 99 Devices that are managed by NETCONF and perhaps other mechanisms have 100 common properties that need to be configured and monitored in a 101 standard way. 103 The "ietf-system" YANG module defined in this document provides the 104 following features: 106 o system identification configuration and monitoring 108 o system time-of-day configuration and monitoring 110 o user authentication configuration 112 o local users configuration 114 o DNS resolver configuration 116 o system control operations (shutdown, restart, setting time) 118 1.1. Terminology 120 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14, [RFC2119]. 125 1.2. Tree Diagrams 127 A simplified graphical representation of the data model is used in 128 this document. The meaning of the symbols in these diagrams is as 129 follows: 131 o Brackets "[" and "]" enclose list keys. 133 o Abbreviations before data node names: "rw" means configuration 134 (read-write) and "ro" state data (read-only). 136 o Symbols after data node names: "?" means an optional node, "!" 137 means a presence container, and "*" denotes a list and leaf-list. 139 o Parentheses enclose choice and case nodes, and case nodes are also 140 marked with a colon (":"). 142 o Ellipsis ("...") stands for contents of subtrees that are not 143 shown. 145 2. Objectives 147 2.1. System Identification 149 There are many common properties used to identify devices, operating 150 systems, software versions, etc. that need to be supported in the 151 system data module. These objects are defined as operational state 152 data and the information returned by the server is intended to be 153 specific to the device vendor. 155 Some user-configurable administrative strings are also provided, such 156 as the system location and description. 158 2.2. System Time Management 160 The management of the date and time used by the system need to be 161 supported. Use of one or more NTP servers to automatically set the 162 system date and time need to be possible. Utilization of the 163 Timezone database [RFC6557] also need to be supported. It should be 164 possible for the server, as well as clients, to configure the system 165 to use NTP. 167 2.3. User Authentication 169 The authentication mechanism need to support password authentication 170 over RADIUS, to support deployment scenarios with centralized 171 authentication servers. Additionally, local users need to be 172 supported, for scenarios when no centralized authentication server 173 exists, or for situations where the centralized authentication server 174 cannot be reached from the device. 176 Since the mandatory transport protocol for NETCONF is SSH [RFC6242] 177 the authentication model need to support SSH's "publickey" and 178 "password" authentication methods [RFC4252]. 180 The model for authentication configuration should be flexible enough 181 to support authentication methods defined by other standard documents 182 or by vendors. It should be possible for the server, as well as 183 clients, to configure the system authentication properties. 185 2.4. DNS Resolver 187 The configuration of the DNS resolver within the system containing 188 the NETCONF server is required to control how domain names are 189 resolved. 191 2.5. System Control 193 A few operations are needed to support common tasks such as 194 restarting the device or setting the system date and time. 196 3. System Data Model 198 3.1. System Identification 200 The data model for system identification has the following structure: 202 +--rw system 203 | +--rw contact? string 204 | +--rw hostname? inet:domain-name 205 | +--rw location? string 206 +--ro system-state 207 +--ro platform 208 +--ro os-name? string 209 +--ro os-release? string 210 +--ro os-version? string 211 +--ro machine? string 213 3.2. System Time Management 215 The data model for system time management has the following 216 structure: 218 +--rw system 219 | +--rw clock 220 | | +--rw (timezone)? 221 | | +--:(timezone-location) 222 | | | +--rw timezone-location? ianatz:iana-timezone 223 | | +--:(timezone-utc-offset) 224 | | +--rw timezone-utc-offset? int16 225 | +--rw ntp! 226 | +--rw enabled? boolean 227 | +--rw server* [name] 228 | +--rw name string 229 | +--rw (transport) 230 | | +--:(udp) 231 | | +--rw udp 232 | | +--rw address inet:host 233 | | +--rw port? inet:port-number 234 | +--rw association-type? enumeration 235 | +--rw iburst? boolean 236 | +--rw prefer? boolean 237 +--ro system-state 238 +--ro clock 239 +--ro current-datetime? yang:date-and-time 240 +--ro boot-datetime? yang:date-and-time 242 New "case" statements can be added over time or augmented to the 243 "transport" choice to support other transport protocols. 245 3.3. DNS Resolver Model 247 The data model for configuration of the DNS resolver has the 248 following structure: 250 +--rw system 251 +--rw dns-resolver 252 +--rw search* inet:domain-name 253 +--rw server* [name] 254 | +--rw name string 255 | +--rw (transport) 256 | +--:(udp-and-tcp) 257 | +--udp-and-tcp 258 | +--rw address inet:ip-address 259 | +--rw port? inet:port-number 260 +--rw options 261 +--rw timeout? uint8 262 +--rw attempts? uint8 264 New "case" statements can be added over time or augmented to the 265 "transport" choice to support other transport protocols. 267 3.4. RADIUS Client Model 269 The data model for configuration of the RADIUS client has the 270 following structure: 272 +--rw system 273 +--rw radius 274 +--rw server* [name] 275 | +--rw name string 276 | +--rw (transport) 277 | | +--:(udp) 278 | | +--rw udp 279 | | +--rw address inet:host 280 | | +--rw authentication-port? inet:port-number 281 | | +--rw shared-secret string 282 | +--rw authentication-type? identityref 283 +--rw options 284 +--rw timeout? uint8 285 +--rw attempts? uint8 287 New "case" statements can be added over time or augmented to the 288 "transport" choice to support other transport protocols. 290 3.5. User Authentication Model 292 This document defines three authentication methods for use with 293 NETCONF: 295 o publickey for local users over SSH 297 o password for local users over any transport 299 o password for RADIUS users over any transport 301 Additional methods can be defined by other standard documents or by 302 vendors. 304 This document defines two optional YANG features, "local-users" and 305 "radius-authentication", which the server advertises to indicate 306 support for configuring local users on the device, and support for 307 using RADIUS for authentication, respectively. 309 The authentication parameters defined in this document are primarily 310 used to configure authentication of NETCONF users, but MAY also be 311 used by other interfaces, e.g., a Command Line Interface or a Web- 312 based User Interface. 314 The data model for user authentication has the following structure: 316 +--rw system 317 +--rw authentication 318 +--rw user-authentication-order* identityref 319 +--rw user* [name] 320 +--rw name string 321 +--rw password? crypt-hash 322 +--rw ssh-key* [name] 323 +--rw name string 324 +--rw algorithm string 325 +--rw key-data binary 327 3.5.1. SSH Public Key Authentication 329 If the NETCONF server advertises the "local-users" feature, 330 configuration of local users and their SSH public keys is supported 331 in the /system/authentication/user list. 333 Public key authentication is requested by the SSH client. If the 334 "local-users" feature is supported, then when a NETCONF client starts 335 an SSH session towards the server using the "publickey" 336 authentication "method name" [RFC4252], the SSH server looks up the 337 user name given in the SSH authentication request in the /system/ 338 authentication/user list, and verifies the key as described in 339 [RFC4253]. 341 3.5.2. Local User Password Authentication 343 If the NETCONF server advertises the "local-users" feature, 344 configuration of local users and their passwords is supported in the 345 /system/authentication/user list. 347 For NETCONF transport protocols that support password authentication, 348 the leaf-list "user-authentication-order" is used to control if local 349 user password authentication should be used. 351 In SSH, password authentication is requested by the client. Other 352 NETCONF transport protocols MAY also support password authentication. 354 When local user password authentication is requested, the NETCONF 355 transport looks up the user name provided by the client in the 356 /system/authentication/user list, and verifies the password. 358 3.5.3. RADIUS Password Authentication 360 If the NETCONF server advertises the "radius-authentication" feature, 361 the device supports user authentication using RADIUS. 363 For NETCONF transport protocols that support password authentication, 364 the leaf-list "user-authentication-order" is used to control if 365 RADIUS password authentication should be used. 367 In SSH, password authentication is requested by the client. Other 368 NETCONF transport protocols MAY also support password authentication. 370 3.6. System Control 372 The following operations are defined: 374 set-current-datetime 375 system-restart 376 system-shutdown 378 Two protocol operations are included to restart or shutdown the 379 system. The 'system-restart' operation can be used to restart the 380 entire system (not just the NETCONF server). The 'system-shutdown' 381 operation can be used to power off the entire system. 383 4. Relationship to the SNMPv2-MIB 385 If a device implements the SNMPv2-MIB [RFC3418], there are two 386 objects that MAY be mapped by the implementation. See the YANG 387 module definition in Section 5 for details. The following table 388 lists the YANG data nodes with corresponding objects in the SNMPv2- 389 MIB. 391 +----------------+-------------------+ 392 | YANG data node | SNMPv2-MIB object | 393 +----------------+-------------------+ 394 | contact | sysContact | 395 | location | sysLocation | 396 +----------------+-------------------+ 398 YANG interface configuration data nodes and related SNMPv2-MIB 399 objects 401 5. System YANG module 403 This YANG module imports YANG extensions from [RFC6536], and imports 404 YANG types from [RFC6991] and [I-D.ietf-netmod-iana-timezones]. It 405 also references [RFC1035], [RFC1321], [RFC2865], [RFC3418], 406 [RFC5607], [RFC5966], [IEEE-1003.1-2008], and [FIPS.180-3.2008]. 408 RFC Ed.: update the date below with the date of RFC publication and 409 remove this note. 411 file "ietf-system@2013-12-23.yang" 413 module ietf-system { 414 namespace "urn:ietf:params:xml:ns:yang:ietf-system"; 415 prefix "sys"; 417 import ietf-yang-types { 418 prefix yang; 419 } 421 import ietf-inet-types { 422 prefix inet; 423 } 425 import ietf-netconf-acm { 426 prefix nacm; 427 } 429 import iana-timezones { 430 prefix ianatz; 431 } 433 organization 434 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 436 contact 437 "WG Web: 438 WG List: 440 WG Chair: David Kessens 441 443 WG Chair: Juergen Schoenwaelder 444 446 Editor: Andy Bierman 447 449 Editor: Martin Bjorklund 450 "; 452 description 453 "This module contains a collection of YANG definitions for the 454 configuration and identification of some common system 455 properties within a device containing a NETCONF server. This 456 includes data node definitions for system identification, 457 time-of-day management, user management, DNS resolver 458 configuration, and some protocol operations for system 459 management. 461 Copyright (c) 2013 IETF Trust and the persons identified as 462 authors of the code. All rights reserved. 464 Redistribution and use in source and binary forms, with or 465 without modification, is permitted pursuant to, and subject 466 to the license terms contained in, the Simplified BSD License 467 set forth in Section 4.c of the IETF Trust's Legal Provisions 468 Relating to IETF Documents 469 (http://trustee.ietf.org/license-info). 471 This version of this YANG module is part of RFC XXXX; see 472 the RFC itself for full legal notices."; 474 // RFC Ed.: replace XXXX with actual RFC number and remove this 475 // note. 477 // RFC Ed.: remove this note 478 // Note: extracted from draft-ietf-netmod-system-mgmt-07.txt 480 // RFC Ed.: update the date below with the date of RFC publication 481 // and remove this note. 482 revision "2013-12-23" { 483 description 484 "Initial revision."; 485 reference 486 "RFC XXXX: A YANG Data Model for System Management"; 487 } 489 /* 490 * Typedefs 491 */ 493 typedef crypt-hash { 494 type string { 495 pattern 496 '$0$.*' 498 + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}' 499 + '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}' 500 + '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}'; 501 } 502 description 503 "The crypt-hash type is used to store passwords using 504 a hash function. The algorithms for applying the hash 505 function and encoding the result are implemented in 506 various UNIX systems as the function crypt(3). 508 A value of this type matches one of the forms: 510 $0$ 511 $$$ 512 $$$$ 514 The '$0$' prefix signals that the value is clear text. When 515 such a value is received by the server, a hash value is 516 calculated, and the string '$$$' or 517 $$$$ is prepended to the result. This 518 value is stored in the configuration data store. 520 If a value starting with '$$', where is not '0', is 521 received, the server knows that the value already represents a 522 hashed value, and stores it as is in the data store. 524 When a server needs to verify a password given by a user, it 525 finds the stored password hash string for that user, extracts 526 the salt, and calculates the hash with the salt and given 527 password as input. If the calculated hash value is the same 528 as the stored value, the password given by the client is 529 accepted. 531 This type defines the following hash functions: 533 id | hash function | feature 534 ---+---------------+------------------- 535 1 | MD5 | crypt-hash-md5 536 5 | SHA-256 | crypt-hash-sha-256 537 6 | SHA-512 | crypt-hash-sha-512 539 The server indicates support for the different hash functions 540 by advertising the corresponding feature."; 541 reference 542 "IEEE Std 1003.1-2008 - crypt() function 543 Wikipedia: http://en.wikipedia.org/wiki/Crypt_(C) 544 RFC 1321: The MD5 Message-Digest Algorithm 545 FIPS.180-3.2008: Secure Hash Standard"; 547 } 549 /* 550 * Features 551 */ 553 feature radius { 554 description 555 "Indicates that the device can be configured as a RADIUS 556 client."; 557 reference 558 "RFC 2865: Remote Authentication Dial In User Service " 559 + "(RADIUS)"; 560 } 562 feature authentication { 563 description 564 "Indicates that the device supports configuration 565 for user authentication."; 566 } 568 feature local-users { 569 if-feature authentication; 570 description 571 "Indicates that the device supports configuration of 572 local user authentication."; 573 } 575 feature radius-authentication { 576 if-feature radius; 577 if-feature authentication; 578 description 579 "Indicates that the device supports configuration of user 580 authentication over RADIUS."; 581 reference 582 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 583 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 584 Authorization for Network Access Server (NAS) 585 Management"; 586 } 588 feature crypt-hash-md5 { 589 description 590 "Indicates that the device supports the MD5 591 hash function in 'crypt-hash' values"; 592 reference "RFC 1321: The MD5 Message-Digest Algorithm"; 593 } 594 feature crypt-hash-sha-256 { 595 description 596 "Indicates that the device supports the SHA-256 597 hash function in 'crypt-hash' values"; 598 reference "FIPS.180-3.2008: Secure Hash Standard"; 599 } 601 feature crypt-hash-sha-512 { 602 description 603 "Indicates that the device supports the SHA-512 604 hash function in 'crypt-hash' values"; 605 reference "FIPS.180-3.2008: Secure Hash Standard"; 606 } 608 feature ntp { 609 description 610 "Indicates that the device can be configured 611 to use one or more NTP servers to set the 612 system date and time."; 613 } 615 feature ntp-udp-port { 616 description 617 "Indicates that the device supports the configuration of 618 the UDP port for NTP servers. 620 This is a 'feature' since many implementations do not support 621 any other port than the default port."; 622 } 624 feature timezone-location { 625 description 626 "Indicates that the local timezone on the device 627 can be configured to use the TZ database 628 to set the timezone and manage daylight savings time."; 629 reference 630 "TZ Database http://www.twinsun.com/tz/tz-link.htm 631 Maintaining the Timezone Database 632 RFC 6557 (BCP 175)"; 633 } 635 feature dns-udp-tcp-port { 636 description 637 "Indicates that the device supports the configuration of 638 the UDP and TCP port for DNS servers. 640 This is a 'feature' since many implementations do not support 641 any other port than the default port."; 643 } 645 /* 646 * Identities 647 */ 649 identity authentication-method { 650 description 651 "Base identity for user authentication methods."; 652 } 654 identity radius { 655 base authentication-method; 656 description 657 "Indicates user authentication using RADIUS."; 658 reference 659 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 660 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 661 Authorization for Network Access Server (NAS) 662 Management"; 663 } 665 identity local-users { 666 base authentication-method; 667 description 668 "Indicates password-based authentication of locally 669 configured users."; 670 } 672 identity radius-authentication-type { 673 description 674 "Base identity for RADIUS authentication types."; 675 } 677 identity radius-pap { 678 base radius-authentication-type; 679 description 680 "The device requests PAP authentication from the RADIUS 681 server."; 682 reference 683 "RFC 2865: Remote Authentication Dial In User Service"; 684 } 686 identity radius-chap { 687 base radius-authentication-type; 688 description 689 "The device requests CHAP authentication from the RADIUS 690 server."; 692 reference 693 "RFC 2865: Remote Authentication Dial In User Service"; 694 } 696 /* 697 * Configuration data nodes 698 */ 700 container system { 701 description 702 "System group configuration."; 704 leaf contact { 705 type string; 706 description 707 "The administrator contact information for the system. 709 A server implementation MAY map this leaf to the sysContact 710 MIB object. Such an implementation needs to use some 711 mechanism to handle the differences in size and characters 712 allowed between this leaf and sysContact. The definition of 713 such a mechanism is outside the scope of this document."; 714 reference 715 "RFC 3418: Management Information Base (MIB) for the 716 Simple Network Management Protocol (SNMP) 717 SNMPv2-MIB.sysContact"; 718 } 719 leaf hostname { 720 type inet:domain-name; 721 description 722 "The name of the host. This name can be a single domain 723 label, or the fully qualified domain name of the host."; 724 } 725 leaf location { 726 type string; 727 description 728 "The system location. 730 A server implementation MAY map this leaf to the sysLocation 731 MIB object. Such an implementation needs to use some 732 mechanism to handle the differences in size and characters 733 allowed between this leaf and sysLocation. The definition 734 of such a mechanism is outside the scope of this document."; 735 reference 736 "RFC 3418: Management Information Base (MIB) for the 737 Simple Network Management Protocol (SNMP) 738 SNMPv2-MIB.sysLocation"; 739 } 740 container clock { 741 description 742 "Configuration of the system date and time properties."; 744 choice timezone { 745 description 746 "The system timezone information."; 748 case timezone-location { 749 if-feature timezone-location; 750 leaf timezone-location { 751 type ianatz:iana-timezone; 752 description 753 "The TZ database location identifier string 754 to use for the system, such as 'Europe/Stockholm'."; 755 } 756 } 757 case timezone-utc-offset { 758 leaf timezone-utc-offset { 759 type int16 { 760 range "-1500 .. 1500"; 761 } 762 units "minutes"; 763 description 764 "The number of minutes to add to UTC time to 765 identify the timezone for this system. For example, 766 'UTC - 8:00 hours' would be represented as '-480'. 767 Note that automatic daylight savings time adjustment 768 is not provided, if this object is used."; 769 } 770 } 771 } 772 } 774 container ntp { 775 if-feature ntp; 776 presence 777 "Enables the NTP client unless the 'enabled' leaf 778 (which defaults to 'true') is set to 'false'"; 779 description 780 "Configuration of the NTP client."; 782 leaf enabled { 783 type boolean; 784 default true; 785 description 786 "Indicates that the system should attempt 787 to synchronize the system clock with an 788 NTP server from the 'ntp/server' list."; 789 } 790 list server { 791 key name; 792 description 793 "List of NTP servers to use for 794 system clock synchronization. If '/system/ntp/enabled' 795 is 'true', then the system will attempt to 796 contact and utilize the specified NTP servers."; 798 leaf name { 799 type string; 800 description 801 "An arbitrary name for the NTP server."; 802 } 803 choice transport { 804 mandatory true; 805 description 806 "The transport protocol specific parameters for this 807 server."; 809 case udp { 810 container udp { 811 description 812 "Contains UDP specific configuration parameters 813 for NTP."; 814 leaf address { 815 type inet:host; 816 mandatory true; 817 description 818 "The address of the NTP server."; 819 } 820 leaf port { 821 if-feature ntp-udp-port; 822 type inet:port-number; 823 default 123; 824 description 825 "The port number of the NTP server."; 826 } 827 } 828 } 829 } 830 leaf association-type { 831 type enumeration { 832 enum server { 833 description 834 "Use client association mode. This device 835 will not provide synchronization to the 836 configured NTP server."; 837 } 838 enum peer { 839 description 840 "Use symmetric active association mode. 841 This device may provide synchronization 842 to the configured NTP server."; 843 } 844 enum pool { 845 description 846 "Use client association mode with one or 847 more of the NTP servers found by DNS 848 resolution of the domain name given by 849 the 'address' leaf. This device will not 850 provide synchronization to the servers."; 851 } 852 } 853 default server; 854 description 855 "The desired association type for this NTP server."; 856 } 857 leaf iburst { 858 type boolean; 859 default false; 860 description 861 "Indicates whether this server should enable burst 862 synchronization or not."; 863 } 864 leaf prefer { 865 type boolean; 866 default false; 867 description 868 "Indicates whether this server should be preferred 869 or not."; 870 } 871 } 872 } 874 container dns-resolver { 875 description 876 "Configuration of the DNS resolver."; 878 leaf-list search { 879 type inet:domain-name; 880 ordered-by user; 881 description 882 "An ordered list of domains to search when resolving 883 a host name."; 885 } 886 list server { 887 key name; 888 ordered-by user; 889 description 890 "List of the DNS servers that the resolver should query. 892 When the resolver is invoked by a calling application, it 893 sends the query to the first name server in this list. If 894 no response has been received within 'timeout' seconds, 895 the resolver continues with the next server in the list. 896 If no response is received from any server, the resolver 897 continues with the first server again. When the resolver 898 has traversed the list 'attempts' times without receiving 899 any response, it gives up and returns an error to the 900 calling application. 902 Implementations MAY limit the number of entries in this 903 list."; 905 leaf name { 906 type string; 907 description 908 "An arbitrary name for the DNS server."; 909 } 910 choice transport { 911 mandatory true; 912 description 913 "The transport protocol specific parameters for this 914 server."; 916 case udp-and-tcp { 917 container udp-and-tcp { 918 description 919 "Contains UDP and TCP specific configuration 920 parameters for DNS."; 921 reference 922 "RFC 1035: Domain Implementation and Specification 923 RFC 5966: DNS over TCP"; 925 leaf address { 926 type inet:ip-address; 927 mandatory true; 928 description 929 "The address of the DNS server."; 930 } 931 leaf port { 932 if-feature dns-udp-tcp-port; 933 type inet:port-number; 934 default 53; 935 description 936 "The UDP and TCP port number of the DNS server."; 937 } 938 } 939 } 940 } 941 } 942 container options { 943 description 944 "Resolver options. The set of available options has been 945 limited to those that are generally available across 946 different resolver implementations, and generally 947 useful."; 948 leaf timeout { 949 type uint8 { 950 range "1..max"; 951 } 952 units "seconds"; 953 default "5"; 954 description 955 "The amount of time the resolver will wait for a 956 response from each remote name server before 957 retrying the query via a different name server."; 958 } 959 leaf attempts { 960 type uint8 { 961 range "1..max"; 962 } 963 default "2"; 964 description 965 "The number of times the resolver will send a query to 966 all its name servers before giving up and returning an 967 error to the calling application."; 968 } 969 } 970 } 972 container radius { 973 if-feature radius; 975 description 976 "Configuration of the RADIUS client."; 978 list server { 979 key name; 980 ordered-by user; 981 description 982 "List of RADIUS servers used by the device. 984 When the RADIUS client is invoked by a calling 985 application, it sends the query to the first server in 986 this list. If no response has been received within 987 'timeout' seconds, the client continues with the next 988 server in the list. If no response is received from any 989 server, the client continues with the first server again. 990 When the client has traversed the list 'attempts' times 991 without receiving any response, it gives up and returns an 992 error to the calling application."; 994 leaf name { 995 type string; 996 description 997 "An arbitrary name for the RADIUS server."; 998 } 999 choice transport { 1000 mandatory true; 1001 description 1002 "The transport protocol specific parameters for this 1003 server."; 1005 case udp { 1006 container udp { 1007 description 1008 "Contains UDP specific configuration parameters 1009 for RADIUS."; 1010 leaf address { 1011 type inet:host; 1012 mandatory true; 1013 description 1014 "The address of the RADIUS server."; 1015 } 1016 leaf authentication-port { 1017 type inet:port-number; 1018 default "1812"; 1019 description 1020 "The port number of the RADIUS server."; 1021 } 1022 leaf shared-secret { 1023 type string; 1024 mandatory true; 1025 nacm:default-deny-all; 1026 description 1027 "The shared secret which is known to both the 1028 RADIUS client and server."; 1030 reference 1031 "RFC 2865: Remote Authentication Dial In User 1032 Service"; 1033 } 1034 } 1035 } 1036 } 1037 leaf authentication-type { 1038 type identityref { 1039 base radius-authentication-type; 1040 } 1041 default radius-pap; 1042 description 1043 "The authentication type requested from the RADIUS 1044 server."; 1045 } 1046 } 1047 container options { 1048 description 1049 "RADIUS client options."; 1051 leaf timeout { 1052 type uint8 { 1053 range "1..max"; 1054 } 1055 units "seconds"; 1056 default "5"; 1057 description 1058 "The number of seconds the device will wait for a 1059 response from each RADIUS server before trying with a 1060 different server."; 1061 } 1062 leaf attempts { 1063 type uint8 { 1064 range "1..max"; 1065 } 1066 default "2"; 1067 description 1068 "The number of times the device will send a query to 1069 all its RADIUS servers before giving up."; 1070 } 1071 } 1072 } 1074 container authentication { 1075 nacm:default-deny-write; 1076 if-feature authentication; 1077 description 1078 "The authentication configuration subtree."; 1080 leaf-list user-authentication-order { 1081 type identityref { 1082 base authentication-method; 1083 } 1084 must '(. != "sys:radius" or ../../radius/server)' { 1085 error-message 1086 "When 'radius' is used, a RADIUS server" 1087 + " must be configured."; 1088 description 1089 "When 'radius' is used as an authentication method, 1090 a RADIUS server must be configured."; 1091 } 1092 ordered-by user; 1094 description 1095 "When the device authenticates a user with 1096 a password, it tries the authentication methods in this 1097 leaf-list in order. If authentication with one method 1098 fails, the next method is used. If no method succeeds, 1099 the user is denied access. 1101 If the 'radius-authentication' feature is advertised by 1102 the NETCONF server, the 'radius' identity can be added to 1103 this list. 1105 If the 'local-users' feature is advertised by the 1106 NETCONF server, the 'local-users' identity can be 1107 added to this list."; 1108 } 1110 list user { 1111 if-feature local-users; 1112 key name; 1113 description 1114 "The list of local users configured on this device."; 1116 leaf name { 1117 type string; 1118 description 1119 "The user name string identifying this entry."; 1120 } 1121 leaf password { 1122 type crypt-hash; 1123 description 1124 "The password for this entry."; 1126 } 1127 list ssh-key { 1128 key name; 1129 description 1130 "A list of public SSH keys for this user."; 1131 reference 1132 "RFC 4253: The Secure Shell (SSH) Transport Layer 1133 Protocol"; 1135 leaf name { 1136 type string; 1137 description 1138 "An arbitrary name for the ssh key."; 1139 } 1140 leaf algorithm { 1141 type string; 1142 mandatory true; 1143 description 1144 "The public key algorithm name for this ssh key. 1146 Valid values are the values in the IANA Secure Shell 1147 (SSH) Protocol Parameters registry, Public Key 1148 Algorithm Names"; 1149 reference 1150 "IANA Secure Shell (SSH) Protocol Parameters registry, 1151 Public Key Algorithm Names"; 1152 } 1153 leaf key-data { 1154 type binary; 1155 mandatory true; 1156 description 1157 "The binary key data for this ssh key."; 1158 } 1159 } 1160 } 1161 } 1162 } 1164 /* 1165 * Operational state data nodes 1166 */ 1168 container system-state { 1169 config false; 1170 description 1171 "System group operational state."; 1173 container platform { 1174 description 1175 "Contains vendor-specific information for 1176 identifying the system platform and operating system."; 1177 reference 1178 "IEEE Std 1003.1-2008 - sys/utsname.h"; 1180 leaf os-name { 1181 type string; 1182 description 1183 "The name of the operating system in use, 1184 for example 'Linux'"; 1185 reference 1186 "IEEE Std 1003.1-2008 - utsname.sysname"; 1187 } 1188 leaf os-release { 1189 type string; 1190 description 1191 "The current release level of the operating 1192 system in use. This string MAY indicate 1193 the OS source code revision."; 1194 reference 1195 "IEEE Std 1003.1-2008 - utsname.release"; 1196 } 1197 leaf os-version { 1198 type string; 1199 description 1200 "The current version level of the operating 1201 system in use. This string MAY indicate 1202 the specific OS build date and target variant 1203 information."; 1204 reference 1205 "IEEE Std 1003.1-2008 - utsname.version"; 1206 } 1207 leaf machine { 1208 type string; 1209 description 1210 "A vendor-specific identifier string representing 1211 the hardware in use."; 1212 reference 1213 "IEEE Std 1003.1-2008 - utsname.machine"; 1214 } 1215 } 1217 container clock { 1218 description 1219 "Monitoring of the system 1220 date and time properties."; 1222 leaf current-datetime { 1223 type yang:date-and-time; 1224 description 1225 "The current system date and time."; 1226 } 1227 leaf boot-datetime { 1228 type yang:date-and-time; 1229 description 1230 "The system date and time when the system last restarted."; 1231 } 1232 } 1233 } 1235 rpc set-current-datetime { 1236 nacm:default-deny-all; 1237 description 1238 "Set the /system-state/clock/current-datetime leaf 1239 to the specified value. 1241 If the system is using NTP (i.e., /system/ntp/enabled 1242 is set to 'true'), then this operation will 1243 fail with error-tag 'operation-failed', 1244 and error-app-tag value of 'ntp-active'"; 1245 input { 1246 leaf current-datetime { 1247 type yang:date-and-time; 1248 mandatory true; 1249 description 1250 "The current system date and time."; 1251 } 1252 } 1253 } 1255 rpc system-restart { 1256 nacm:default-deny-all; 1257 description 1258 "Request that the entire system be restarted immediately. 1259 A server SHOULD send an rpc reply to the client before 1260 restarting the system."; 1261 } 1263 rpc system-shutdown { 1264 nacm:default-deny-all; 1265 description 1266 "Request that the entire system be shut down immediately. 1267 A server SHOULD send an rpc reply to the client before 1268 shutting down the system."; 1269 } 1271 } 1273 1275 6. IANA Considerations 1277 This document registers one URI in the IETF XML registry [RFC3688]. 1278 Following the format in RFC 3688, the following registration is 1279 requested to be made. 1281 URI: urn:ietf:params:xml:ns:yang:ietf-system 1282 Registrant Contact: The NETMOD WG of the IETF. 1283 XML: N/A, the requested URI is an XML namespace. 1285 This document registers one YANG module in the YANG Module Names 1286 registry [RFC6020]. 1288 name: ietf-system 1289 namespace: urn:ietf:params:xml:ns:yang:ietf-system 1290 prefix: sys 1291 reference: RFC XXXX 1293 7. Security Considerations 1295 The YANG module defined in this memo is designed to be accessed via 1296 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1297 secure transport layer and the mandatory-to-implement secure 1298 transport is SSH [RFC6242]. Authorization for access to specific 1299 portions of conceptual data and operations within this module is 1300 provided by the NETCONF access control model (NACM) [RFC6536]. 1302 There are a number of data nodes defined in this YANG module which 1303 are writable/creatable/deletable (i.e., config true, which is the 1304 default). These data nodes may be considered sensitive or vulnerable 1305 in some network environments. Write operations (e.g., edit-config) 1306 to these data nodes without proper protection can have a negative 1307 effect on network operations. These are the subtrees and data nodes 1308 and their sensitivity/vulnerability: 1310 o /system/clock/timezone: This choice contains the objects used to 1311 control the timezone used by the device. 1313 o /system/ntp: This container contains the objects used to control 1314 the Network Time Protocol servers used by the device. 1316 o /system/dns-resolver: This container contains the objects used to 1317 control the Domain Name System servers used by the device. 1319 o /system/radius: This container contains the objects used to 1320 control the Remote Authentication Dial-In User Service servers 1321 used by the device. 1323 o /system/authentication/user-authentication-order: This leaf 1324 controls how user login attempts are authenticated by the device. 1326 o /system/authentication/user: This list contains the local users 1327 enabled on the system. 1329 Some of the readable data nodes in this YANG module may be considered 1330 sensitive or vulnerable in some network environments. It is thus 1331 important to control read access (e.g., via get, get-config, or 1332 notification) to these data nodes. These are the subtrees and data 1333 nodes and their sensitivity/vulnerability: 1335 o /system/platform: This container has objects which may help 1336 identify the specific NETCONF server and/or operating system 1337 implementation used on the device. 1339 o /system/authentication/user: This list has objects that may help 1340 identify the specific user names and password information in use 1341 on the device. 1343 Some of the RPC operations in this YANG module may be considered 1344 sensitive or vulnerable in some network environments. It is thus 1345 important to control access to these operations. These are the 1346 operations and their sensitivity/vulnerability: 1348 o set-current-datetime: Changes the current date and time on the 1349 device. 1351 o system-restart: Reboots the device. 1353 o system-shutdown: Shuts down the device. 1355 This YANG model defines a type "crypt-hash" that can be used to store 1356 MD5 hashes. [RFC6151] discusses security considerations for MD5. 1358 8. Change Log 1360 -- RFC Ed.: remove this section before publication. 1362 8.1. 00-01 1364 o added configuration-source identities 1366 o added configuration-source leaf to ntp and dns (via grouping) to 1367 choose configuration source 1369 o added association-type, iburst, prefer, and true leafs to the ntp- 1370 server list 1372 o extended the ssh keys for a user to a list of keys. support all 1373 defined key algorithms, not just dsa and rsa 1375 o clarified timezone-utc-offset description-stmt 1377 o removed '/system/ntp/server/true' leaf from data model 1379 8.2. 01-02 1381 o added default-stmts to ntp-server/iburst and ntp-server/prefer 1382 leafs 1384 o changed timezone-location leaf to use iana-timezone typedef 1385 instead of a string 1387 8.3. 02-03 1389 o removed configuration-source identities and leafs 1391 8.4. 03-04 1393 o removed ndots dns resolver option 1395 o added radius-authentication-type identity, and identities for pap 1396 and chap, and a leaf to control which authentication type to use 1397 when communicating with the radius server 1399 o made 0 an invalid value for timeouts and attempts 1401 8.5. 04-05 1403 o updated tree diagram explanation text 1405 8.6. 05-06 1407 o changed ntp/use-ntp to ntp/enabled 1409 o changed ntp/ntp-server to ntp/server 1411 o removed /system/platform/nodename leaf 1413 o changed /system/name to /system/hostname 1415 o simplified must expression in user-authentication-order 1417 o added optional rounds to sha hash definition 1419 o clarified the crypt-hash description 1421 o clarified ntp descriptions 1423 o clarified YANG module description to indicate that some system 1424 properties are supported, not the entire system 1426 o clarified that system identification values are vendor specific, 1427 not the data node objects 1429 o clarified sec. 2.2 and 2.3 to indicate that the server should also 1430 be capable of configuring these properties 1432 o changed /system/dns/search from inet:host to inet:domain-name 1434 o changed RFC6021 reference to 6021-bis 1436 o changed /system/platform/nodename to /system/platform/hostname 1438 o changed /system/radius/server/{leafs} to be within a choice and 1439 'udp' case statement so other transport specific parameters can 1440 augment this list or they can be added by the WG to a future 1441 version of this module. {leafs} are authentication-port and 1442 shared-secret. 1444 o updated YANG tree diagrams for objects added in -05 and -06 1446 8.7. 06-07 1448 o updated the Abstract and Introduction 1450 o updated Tree diagram notation 1451 o identify all external servers (dns, ntp, radius) by name instead 1452 of address, in order to make the data model extensible for 1453 additional transport protocol. 1455 o updated the Security Considerations section with a reference to 1456 NACM. 1458 8.8. 07-08 1460 o renamed the DNS transport to 'udp-and-tcp' and added references. 1462 o moved the operational state nodes into /system-state. 1464 8.9. 08-09 1466 o made "ntp" node a presence container 1468 o added reference to RFC 6151 1470 o updated reference from 6021-bis to RFC 6991 1472 o cleaned up usage of config false in the YANG module 1474 8.10. 09-10 1476 o clarified relationship with SNMPv2-MIB 1478 9. References 1480 9.1. Normative References 1482 [FIPS.180-3.2008] 1483 National Institute of Standards and Technology, "Secure 1484 Hash Standard", FIPS PUB 180-3, October 2008, . 1488 [I-D.ietf-netmod-iana-timezones] 1489 Lange, J., "IANA Timezone Database YANG Module", 1490 draft-ietf-netmod-iana-timezones-00 (work in progress), 1491 July 2012. 1493 [IEEE-1003.1-2008] 1494 Institute of Electrical and Electronics Engineers, 1495 "POSIX.1-2008", IEEE Standard 1003.1, March 2008. 1497 [RFC1035] Mockapetris, P., "Domain names - implementation and 1498 specification", STD 13, RFC 1035, November 1987. 1500 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1501 April 1992. 1503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1504 Requirement Levels", BCP 14, RFC 2119, March 1997. 1506 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1507 "Remote Authentication Dial In User Service (RADIUS)", 1508 RFC 2865, June 2000. 1510 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1511 Simple Network Management Protocol (SNMP)", STD 62, 1512 RFC 3418, December 2002. 1514 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1515 Authentication Protocol", RFC 4252, January 2006. 1517 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1518 Transport Layer Protocol", RFC 4253, January 2006. 1520 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 1521 User Service (RADIUS) Authorization for Network Access 1522 Server (NAS) Management", RFC 5607, July 2009. 1524 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 1525 Requirements", RFC 5966, August 2010. 1527 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1528 Network Configuration Protocol (NETCONF)", RFC 6020, 1529 October 2010. 1531 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1532 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1533 RFC 6151, March 2011. 1535 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1536 and A. Bierman, Ed., "Network Configuration Protocol 1537 (NETCONF)", RFC 6241, June 2011. 1539 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1540 Shell (SSH)", RFC 6242, June 2011. 1542 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1543 Protocol (NETCONF) Access Control Model", RFC 6536, 1544 March 2012. 1546 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1547 July 2013. 1549 9.2. Informative References 1551 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1552 January 2004. 1554 [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the 1555 Time Zone Database", BCP 175, RFC 6557, February 2012. 1557 Authors' Addresses 1559 Andy Bierman 1560 YumaWorks 1562 Email: andy@yumaworks.com 1564 Martin Bjorklund 1565 Tail-f Systems 1567 Email: mbj@tail-f.com