idnits 2.17.1 draft-ietf-netmod-system-mgmt-16.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 246 has weird spacing: '...address ine...' == Line 268 has weird spacing: '...rw name str...' == Line 272 has weird spacing: '...address ine...' == Line 338 has weird spacing: '...gorithm str...' == Line 1251 has weird spacing: '... string cer...' == 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 (May 14, 2014) is 3628 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 5226 (Obsoleted by RFC 8126) ** 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: 5 errors (**), 0 flaws (~~), 7 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: November 15, 2014 Tail-f Systems 6 May 14, 2014 8 A YANG Data Model for System Management 9 draft-ietf-netmod-system-mgmt-16 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 November 15, 2014. 37 Copyright Notice 39 Copyright (c) 2014 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. IANA Crypt Hash YANG module . . . . . . . . . . . . . . . . . 12 75 6. System YANG module . . . . . . . . . . . . . . . . . . . . . . 15 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 78 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 36 79 9.1. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 80 9.2. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 81 9.3. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 82 9.4. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 83 9.5. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 84 9.6. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 37 85 9.7. 06-07 . . . . . . . . . . . . . . . . . . . . . . . . . . 37 86 9.8. 07-08 . . . . . . . . . . . . . . . . . . . . . . . . . . 38 87 9.9. 08-09 . . . . . . . . . . . . . . . . . . . . . . . . . . 38 88 9.10. 09-10 . . . . . . . . . . . . . . . . . . . . . . . . . . 38 89 9.11. 11-12 . . . . . . . . . . . . . . . . . . . . . . . . . . 38 90 9.12. 13-14 . . . . . . . . . . . . . . . . . . . . . . . . . . 38 91 9.13. 14-15 . . . . . . . . . . . . . . . . . . . . . . . . . . 38 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 97 1. Introduction 99 This document defines a YANG [RFC6020] data model for the 100 configuration and identification of some common properties within a 101 device containing a NETCONF server. 103 Devices that are managed by NETCONF and perhaps other mechanisms have 104 common properties that need to be configured and monitored in a 105 standard way. 107 The "ietf-system" YANG module defined in this document provides the 108 following features: 110 o system identification configuration and monitoring 112 o system time-of-day configuration and monitoring 114 o user authentication configuration 116 o local users configuration 118 o DNS resolver configuration 120 o system control operations (shutdown, restart, setting time) 122 1.1. Terminology 124 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14, [RFC2119]. 129 The following terms are defined in [RFC6241] and are not redefined 130 here: 132 o client 134 o configuration data 136 o server 138 o state data 140 1.2. Tree Diagrams 142 A simplified graphical representation of the data model is used in 143 this document. The meaning of the symbols in these diagrams is as 144 follows: 146 o Brackets "[" and "]" enclose list keys. 148 o Abbreviations before data node names: "rw" means configuration 149 (read-write) and "ro" state data (read-only). 151 o Symbols after data node names: "?" means an optional node, "!" 152 means a presence container, and "*" denotes a list and leaf-list. 154 o Parentheses enclose choice and case nodes, and case nodes are also 155 marked with a colon (":"). 157 o Ellipsis ("...") stands for contents of subtrees that are not 158 shown. 160 2. Objectives 162 2.1. System Identification 164 There are many common properties used to identify devices, operating 165 systems, software versions, etc. that need to be supported in the 166 system data module. These objects are defined as operational state 167 data and the information returned by the server is intended to be 168 specific to the device vendor. 170 Some user-configurable administrative strings are also provided, such 171 as the system location and description. 173 2.2. System Time Management 175 The management of the date and time used by the system need to be 176 supported. Use of one or more NTP servers to automatically set the 177 system date and time need to be possible. Utilization of the 178 Timezone database [RFC6557] also need to be supported. It should be 179 possible to configure the system to use NTP. 181 2.3. User Authentication 183 The authentication mechanism needs to support password authentication 184 over RADIUS, to support deployment scenarios with centralized 185 authentication servers. Additionally, local users need to be 186 supported, for scenarios when no centralized authentication server 187 exists, or for situations where the centralized authentication server 188 cannot be reached from the device. 190 Since the mandatory transport protocol for NETCONF is SSH [RFC6242] 191 the authentication model needs to support SSH's "publickey" and 192 "password" authentication methods [RFC4252]. 194 The model for authentication configuration should be flexible enough 195 to support authentication methods defined by other standard documents 196 or by vendors. It should be possible to configure the system 197 authentication properties. 199 2.4. DNS Resolver 201 The configuration of the DNS resolver within the system containing 202 the NETCONF server is required in order to control how domain names 203 are resolved. 205 2.5. System Control 207 A few operations are needed to support common tasks such as 208 restarting the device or setting the system date and time. 210 3. System Data Model 212 3.1. System Identification 214 The data model for system identification has the following structure: 216 +--rw system 217 | +--rw contact? string 218 | +--rw hostname? inet:domain-name 219 | +--rw location? string 220 +--ro system-state 221 +--ro platform 222 +--ro os-name? string 223 +--ro os-release? string 224 +--ro os-version? string 225 +--ro machine? string 227 3.2. System Time Management 229 The data model for system time management has the following 230 structure: 232 +--rw system 233 | +--rw clock 234 | | +--rw (timezone)? 235 | | +--:(timezone-name) 236 | | | +--rw timezone-name? timezone-name 237 | | +--:(timezone-utc-offset) 238 | | +--rw timezone-utc-offset? int16 239 | +--rw ntp! 240 | +--rw enabled? boolean 241 | +--rw server* [name] 242 | +--rw name string 243 | +--rw (transport) 244 | | +--:(udp) 245 | | +--rw udp 246 | | +--rw address inet:host 247 | | +--rw port? inet:port-number 248 | +--rw association-type? enumeration 249 | +--rw iburst? boolean 250 | +--rw prefer? boolean 251 +--ro system-state 252 +--ro clock 253 +--ro current-datetime? yang:date-and-time 254 +--ro boot-datetime? yang:date-and-time 256 New "case" statements can be added over time or augmented to the 257 "transport" choice to support other transport protocols. 259 3.3. DNS Resolver Model 261 The data model for configuration of the DNS resolver has the 262 following structure: 264 +--rw system 265 +--rw dns-resolver 266 +--rw search* inet:domain-name 267 +--rw server* [name] 268 | +--rw name string 269 | +--rw (transport) 270 | +--:(udp-and-tcp) 271 | +--udp-and-tcp 272 | +--rw address inet:ip-address 273 | +--rw port? inet:port-number 274 +--rw options 275 +--rw timeout? uint8 276 +--rw attempts? uint8 278 New "case" statements can be added over time or augmented to the 279 "transport" choice to support other transport protocols. 281 3.4. RADIUS Client Model 283 The data model for configuration of the RADIUS client has the 284 following structure: 286 +--rw system 287 +--rw radius 288 +--rw server* [name] 289 | +--rw name string 290 | +--rw (transport) 291 | | +--:(udp) 292 | | +--rw udp 293 | | +--rw address inet:host 294 | | +--rw authentication-port? inet:port-number 295 | | +--rw shared-secret string 296 | +--rw authentication-type? identityref 297 +--rw options 298 +--rw timeout? uint8 299 +--rw attempts? uint8 301 New "case" statements can be added over time or augmented to the 302 "transport" choice to support other transport protocols. 304 3.5. User Authentication Model 306 This document defines three authentication methods for use with 307 NETCONF: 309 o publickey for local users over SSH 311 o password for local users over any secure transport 313 o password for RADIUS users over any secure transport 315 Additional methods can be defined by other standard documents or by 316 vendors. 318 This document defines two optional YANG features, "local-users" and 319 "radius-authentication", which the server advertises to indicate 320 support for configuring local users on the device, and support for 321 using RADIUS for authentication, respectively. 323 The authentication parameters defined in this document are primarily 324 used to configure authentication of NETCONF users, but MAY also be 325 used by other interfaces, e.g., a Command Line Interface or a Web- 326 based User Interface. 328 The data model for user authentication has the following structure: 330 +--rw system 331 +--rw authentication 332 +--rw user-authentication-order* identityref 333 +--rw user* [name] 334 +--rw name string 335 +--rw password? ianach:crypt-hash 336 +--rw authorized-key* [name] 337 +--rw name string 338 +--rw algorithm string 339 +--rw key-data binary 341 3.5.1. SSH Public Key Authentication 343 If the NETCONF server advertises the "local-users" feature, 344 configuration of local users and their SSH public keys is supported 345 in the /system/authentication/user list. 347 Public key authentication is requested by the SSH client. If the 348 "local-users" feature is supported, then when a NETCONF client starts 349 an SSH session towards the server using the "publickey" 350 authentication "method name" [RFC4252], the SSH server looks up the 351 user name given in the SSH authentication request in the /system/ 352 authentication/user list, and verifies the key as described in 353 [RFC4253]. 355 3.5.2. Local User Password Authentication 357 If the NETCONF server advertises the "local-users" feature, 358 configuration of local users and their passwords is supported in the 359 /system/authentication/user list. 361 For NETCONF transport protocols that support password authentication, 362 the leaf-list "user-authentication-order" is used to control if local 363 user password authentication should be used. 365 In SSH, password authentication is requested by the client. Other 366 NETCONF transport protocols MAY also support password authentication. 368 When local user password authentication is requested, the NETCONF 369 transport looks up the user name provided by the client in the 370 /system/authentication/user list, and verifies the password. 372 3.5.3. RADIUS Password Authentication 374 If the NETCONF server advertises the "radius-authentication" feature, 375 the device supports user authentication using RADIUS. 377 For NETCONF transport protocols that support password authentication, 378 the leaf-list "user-authentication-order" is used to control if 379 RADIUS password authentication should be used. 381 In SSH, password authentication is requested by the client. Other 382 NETCONF transport protocols MAY also support password authentication. 384 3.6. System Control 386 The following operations are defined: 388 set-current-datetime 389 system-restart 390 system-shutdown 392 Two protocol operations are included to restart or shutdown the 393 system. The 'system-restart' operation can be used to restart the 394 entire system (not just the NETCONF server). The 'system-shutdown' 395 operation can be used to power off the entire system. 397 4. Relationship to the SNMPv2-MIB 399 If a device implements the SNMPv2-MIB [RFC3418], there are two 400 objects that MAY be mapped by the implementation. See the YANG 401 module definition in Section 6 for details. The following table 402 lists the YANG data nodes with corresponding objects in the SNMPv2- 403 MIB. 405 +----------------+-------------------+ 406 | YANG data node | SNMPv2-MIB object | 407 +----------------+-------------------+ 408 | contact | sysContact | 409 | location | sysLocation | 410 +----------------+-------------------+ 412 YANG interface configuration data nodes and related SNMPv2-MIB 413 objects 415 5. IANA Crypt Hash YANG module 417 This YANG module references [RFC1321], [IEEE-1003.1-2008], and 418 [FIPS.180-3.2008]. 420 RFC Ed.: update the date below with the date of RFC publication and 421 remove this note. 423 file "iana-crypt-hash@2014-04-04.yang" 425 module iana-crypt-hash { 426 namespace "urn:ietf:params:xml:ns:yang:iana-crypt-hash"; 427 prefix ianach; 429 organization "IANA"; 430 contact 431 " Internet Assigned Numbers Authority 433 Postal: ICANN 434 4676 Admiralty Way, Suite 330 435 Marina del Rey, CA 90292 437 Tel: +1 310 823 9358 438 E-Mail: iana&iana.org"; 439 description 440 "This YANG module defines a typedef for storing passwords 441 using a hash function, and features to indicate which hash 442 functions are supported by an implementation. 444 The latest revision of this YANG module can be obtained from 445 the IANA web site. 447 Requests for new values should be made to IANA via 448 email (iana&iana.org). 450 Copyright (c) 2014 IETF Trust and the persons identified as 451 authors of the code. All rights reserved. 453 Redistribution and use in source and binary forms, with or 454 without modification, is permitted pursuant to, and subject 455 to the license terms contained in, the Simplified BSD License 456 set forth in Section 4.c of the IETF Trust's Legal Provisions 457 Relating to IETF Documents 458 (http://trustee.ietf.org/license-info). 460 The initial version of this YANG module is part of RFC XXXX; 461 see the RFC itself for full legal notices."; 462 // RFC Ed.: replace XXXX with actual RFC number and remove this 463 // note. 465 // RFC Ed.: update the date below with the date of RFC publication 466 // and remove this note. 467 revision 2014-04-04 { 468 description 469 "Initial revision."; 470 reference 471 "RFC XXXX: A YANG Data Model for System Management"; 472 } 474 typedef crypt-hash { 475 type string { 476 pattern 477 '$0$.*' 478 + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}' 479 + '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}' 480 + '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}'; 481 } 482 description 483 "The crypt-hash type is used to store passwords using 484 a hash function. The algorithms for applying the hash 485 function and encoding the result are implemented in 486 various UNIX systems as the function crypt(3). 488 A value of this type matches one of the forms: 490 $0$ 491 $$$ 492 $$$$ 494 The '$0$' prefix signals that the value is clear text. When 495 such a value is received by the server, a hash value is 496 calculated, and the string '$$$' or 497 $$$$ is prepended to the result. This 498 value is stored in the configuration data store. 500 If a value starting with '$$', where is not '0', is 501 received, the server knows that the value already represents a 502 hashed value, and stores it as is in the data store. 504 When a server needs to verify a password given by a user, it 505 finds the stored password hash string for that user, extracts 506 the salt, and calculates the hash with the salt and given 507 password as input. If the calculated hash value is the same 508 as the stored value, the password given by the client is 509 accepted. 511 This type defines the following hash functions: 513 id | hash function | feature 514 ---+---------------+------------------- 515 1 | MD5 | crypt-hash-md5 516 5 | SHA-256 | crypt-hash-sha-256 517 6 | SHA-512 | crypt-hash-sha-512 519 The server indicates support for the different hash functions 520 by advertising the corresponding feature."; 521 reference 522 "IEEE Std 1003.1-2008 - crypt() function 523 RFC 1321: The MD5 Message-Digest Algorithm 524 FIPS.180-3.2008: Secure Hash Standard"; 525 } 527 feature crypt-hash-md5 { 528 description 529 "Indicates that the device supports the MD5 530 hash function in 'crypt-hash' values"; 531 reference "RFC 1321: The MD5 Message-Digest Algorithm"; 532 } 534 feature crypt-hash-sha-256 { 535 description 536 "Indicates that the device supports the SHA-256 537 hash function in 'crypt-hash' values"; 538 reference "FIPS.180-3.2008: Secure Hash Standard"; 539 } 541 feature crypt-hash-sha-512 { 542 description 543 "Indicates that the device supports the SHA-512 544 hash function in 'crypt-hash' values"; 545 reference "FIPS.180-3.2008: Secure Hash Standard"; 546 } 548 } 550 552 6. System YANG module 554 This YANG module imports YANG extensions from [RFC6536], and imports 555 YANG types from [RFC6991]. It also references [RFC1035], [RFC2865], 556 [RFC3418], [RFC5607], [RFC5966], [RFC6557]. 558 RFC Ed.: update the date below with the date of RFC publication and 559 remove this note. 561 file "ietf-system@2014-05-14.yang" 563 module ietf-system { 564 namespace "urn:ietf:params:xml:ns:yang:ietf-system"; 565 prefix "sys"; 567 import ietf-yang-types { 568 prefix yang; 569 } 571 import ietf-inet-types { 572 prefix inet; 573 } 575 import ietf-netconf-acm { 576 prefix nacm; 577 } 579 import iana-crypt-hash { 580 prefix ianach; 581 } 583 organization 584 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 586 contact 587 "WG Web: 588 WG List: 590 WG Chair: Thomas Nadeau 591 593 WG Chair: Juergen Schoenwaelder 594 596 Editor: Andy Bierman 597 599 Editor: Martin Bjorklund 600 "; 602 description 603 "This module contains a collection of YANG definitions for the 604 configuration and identification of some common system 605 properties within a device containing a NETCONF server. This 606 includes data node definitions for system identification, 607 time-of-day management, user management, DNS resolver 608 configuration, and some protocol operations for system 609 management. 611 Copyright (c) 2014 IETF Trust and the persons identified as 612 authors of the code. All rights reserved. 614 Redistribution and use in source and binary forms, with or 615 without modification, is permitted pursuant to, and subject 616 to the license terms contained in, the Simplified BSD License 617 set forth in Section 4.c of the IETF Trust's Legal Provisions 618 Relating to IETF Documents 619 (http://trustee.ietf.org/license-info). 621 This version of this YANG module is part of RFC XXXX; see 622 the RFC itself for full legal notices."; 624 // RFC Ed.: replace XXXX with actual RFC number and remove this 625 // note. 627 // RFC Ed.: remove this note 628 // Note: extracted from draft-ietf-netmod-system-mgmt-07.txt 630 // RFC Ed.: update the date below with the date of RFC publication 631 // and remove this note. 632 revision "2014-05-14" { 633 description 634 "Initial revision."; 635 reference 636 "RFC XXXX: A YANG Data Model for System Management"; 637 } 639 /* 640 * Typedefs 641 */ 643 typedef timezone-name { 644 type string; 645 description 646 "A timezone name as used by the Time Zone Database, sometimes 647 referred to as the 'Olson Database'. 649 The exact set of valid values is an implementation-specific 650 matter. Client discovery of the exact set of time zone names 651 for a particular server is out of scope."; 652 reference 653 "RFC 6557: Procedures for Maintaining the Time Zone Database"; 654 } 656 /* 657 * Features 658 */ 660 feature radius { 661 description 662 "Indicates that the device can be configured as a RADIUS 663 client."; 664 reference 665 "RFC 2865: Remote Authentication Dial In User Service " 666 + "(RADIUS)"; 667 } 669 feature authentication { 670 description 671 "Indicates that the device supports configuration 672 for user authentication."; 673 } 675 feature local-users { 676 if-feature authentication; 677 description 678 "Indicates that the device supports configuration of 679 local user authentication."; 680 } 682 feature radius-authentication { 683 if-feature radius; 684 if-feature authentication; 685 description 686 "Indicates that the device supports configuration of user 687 authentication over RADIUS."; 688 reference 689 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 690 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 691 Authorization for Network Access Server (NAS) 692 Management"; 693 } 695 feature ntp { 696 description 697 "Indicates that the device can be configured 698 to use one or more NTP servers to set the 699 system date and time."; 700 } 702 feature ntp-udp-port { 703 if-feature ntp; 704 description 705 "Indicates that the device supports the configuration of 706 the UDP port for NTP servers. 708 This is a 'feature' since many implementations do not support 709 any other port than the default port."; 710 } 712 feature timezone-name { 713 description 714 "Indicates that the local timezone on the device 715 can be configured to use the TZ database 716 to set the timezone and manage daylight savings time."; 717 reference 718 "RFC 6557: Procedures for Maintaining the Time Zone Database"; 719 } 721 feature dns-udp-tcp-port { 722 description 723 "Indicates that the device supports the configuration of 724 the UDP and TCP port for DNS servers. 726 This is a 'feature' since many implementations do not support 727 any other port than the default port."; 728 } 730 /* 731 * Identities 732 */ 734 identity authentication-method { 735 description 736 "Base identity for user authentication methods."; 737 } 739 identity radius { 740 base authentication-method; 741 description 742 "Indicates user authentication using RADIUS."; 743 reference 744 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 745 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 746 Authorization for Network Access Server (NAS) 747 Management"; 748 } 750 identity local-users { 751 base authentication-method; 752 description 753 "Indicates password-based authentication of locally 754 configured users."; 755 } 757 identity radius-authentication-type { 758 description 759 "Base identity for RADIUS authentication types."; 760 } 762 identity radius-pap { 763 base radius-authentication-type; 764 description 765 "The device requests PAP authentication from the RADIUS 766 server."; 767 reference 768 "RFC 2865: Remote Authentication Dial In User Service"; 769 } 771 identity radius-chap { 772 base radius-authentication-type; 773 description 774 "The device requests CHAP authentication from the RADIUS 775 server."; 776 reference 777 "RFC 2865: Remote Authentication Dial In User Service"; 778 } 780 /* 781 * Configuration data nodes 782 */ 784 container system { 785 description 786 "System group configuration."; 788 leaf contact { 789 type string; 790 description 791 "The administrator contact information for the system. 793 A server implementation MAY map this leaf to the sysContact 794 MIB object. Such an implementation needs to use some 795 mechanism to handle the differences in size and characters 796 allowed between this leaf and sysContact. The definition of 797 such a mechanism is outside the scope of this document."; 798 reference 799 "RFC 3418: Management Information Base (MIB) for the 800 Simple Network Management Protocol (SNMP) 801 SNMPv2-MIB.sysContact"; 802 } 803 leaf hostname { 804 type inet:domain-name; 805 description 806 "The name of the host. This name can be a single domain 807 label, or the fully qualified domain name of the host."; 808 } 809 leaf location { 810 type string; 811 description 812 "The system location. 814 A server implementation MAY map this leaf to the sysLocation 815 MIB object. Such an implementation needs to use some 816 mechanism to handle the differences in size and characters 817 allowed between this leaf and sysLocation. The definition 818 of such a mechanism is outside the scope of this document."; 819 reference 820 "RFC 3418: Management Information Base (MIB) for the 821 Simple Network Management Protocol (SNMP) 822 SNMPv2-MIB.sysLocation"; 823 } 825 container clock { 826 description 827 "Configuration of the system date and time properties."; 829 choice timezone { 830 description 831 "The system timezone information."; 833 case timezone-name { 834 if-feature timezone-name; 835 leaf timezone-name { 836 type timezone-name; 837 description 838 "The TZ database name to use for the system, such 839 as 'Europe/Stockholm'."; 840 } 842 } 843 case timezone-utc-offset { 844 leaf timezone-utc-offset { 845 type int16 { 846 range "-1500 .. 1500"; 847 } 848 units "minutes"; 849 description 850 "The number of minutes to add to UTC time to 851 identify the timezone for this system. For example, 852 'UTC - 8:00 hours' would be represented as '-480'. 853 Note that automatic daylight savings time adjustment 854 is not provided, if this object is used."; 855 } 856 } 857 } 858 } 860 container ntp { 861 if-feature ntp; 862 presence 863 "Enables the NTP client unless the 'enabled' leaf 864 (which defaults to 'true') is set to 'false'"; 865 description 866 "Configuration of the NTP client."; 868 leaf enabled { 869 type boolean; 870 default true; 871 description 872 "Indicates that the system should attempt 873 to synchronize the system clock with an 874 NTP server from the 'ntp/server' list."; 875 } 876 list server { 877 key name; 878 description 879 "List of NTP servers to use for 880 system clock synchronization. If '/system/ntp/enabled' 881 is 'true', then the system will attempt to 882 contact and utilize the specified NTP servers."; 884 leaf name { 885 type string; 886 description 887 "An arbitrary name for the NTP server."; 888 } 889 choice transport { 890 mandatory true; 891 description 892 "The transport protocol specific parameters for this 893 server."; 895 case udp { 896 container udp { 897 description 898 "Contains UDP specific configuration parameters 899 for NTP."; 900 leaf address { 901 type inet:host; 902 mandatory true; 903 description 904 "The address of the NTP server."; 905 } 906 leaf port { 907 if-feature ntp-udp-port; 908 type inet:port-number; 909 default 123; 910 description 911 "The port number of the NTP server."; 912 } 913 } 914 } 915 } 916 leaf association-type { 917 type enumeration { 918 enum server { 919 description 920 "Use client association mode. This device 921 will not provide synchronization to the 922 configured NTP server."; 923 } 924 enum peer { 925 description 926 "Use symmetric active association mode. 927 This device may provide synchronization 928 to the configured NTP server."; 929 } 930 enum pool { 931 description 932 "Use client association mode with one or 933 more of the NTP servers found by DNS 934 resolution of the domain name given by 935 the 'address' leaf. This device will not 936 provide synchronization to the servers."; 937 } 939 } 940 default server; 941 description 942 "The desired association type for this NTP server."; 943 } 944 leaf iburst { 945 type boolean; 946 default false; 947 description 948 "Indicates whether this server should enable burst 949 synchronization or not."; 950 } 951 leaf prefer { 952 type boolean; 953 default false; 954 description 955 "Indicates whether this server should be preferred 956 or not."; 957 } 958 } 959 } 961 container dns-resolver { 962 description 963 "Configuration of the DNS resolver."; 965 leaf-list search { 966 type inet:domain-name; 967 ordered-by user; 968 description 969 "An ordered list of domains to search when resolving 970 a host name."; 971 } 972 list server { 973 key name; 974 ordered-by user; 975 description 976 "List of the DNS servers that the resolver should query. 978 When the resolver is invoked by a calling application, it 979 sends the query to the first name server in this list. If 980 no response has been received within 'timeout' seconds, 981 the resolver continues with the next server in the list. 982 If no response is received from any server, the resolver 983 continues with the first server again. When the resolver 984 has traversed the list 'attempts' times without receiving 985 any response, it gives up and returns an error to the 986 calling application. 988 Implementations MAY limit the number of entries in this 989 list."; 991 leaf name { 992 type string; 993 description 994 "An arbitrary name for the DNS server."; 995 } 996 choice transport { 997 mandatory true; 998 description 999 "The transport protocol specific parameters for this 1000 server."; 1002 case udp-and-tcp { 1003 container udp-and-tcp { 1004 description 1005 "Contains UDP and TCP specific configuration 1006 parameters for DNS."; 1007 reference 1008 "RFC 1035: Domain Implementation and Specification 1009 RFC 5966: DNS over TCP"; 1011 leaf address { 1012 type inet:ip-address; 1013 mandatory true; 1014 description 1015 "The address of the DNS server."; 1016 } 1017 leaf port { 1018 if-feature dns-udp-tcp-port; 1019 type inet:port-number; 1020 default 53; 1021 description 1022 "The UDP and TCP port number of the DNS server."; 1023 } 1024 } 1025 } 1026 } 1027 } 1028 container options { 1029 description 1030 "Resolver options. The set of available options has been 1031 limited to those that are generally available across 1032 different resolver implementations, and generally 1033 useful."; 1034 leaf timeout { 1035 type uint8 { 1036 range "1..max"; 1037 } 1038 units "seconds"; 1039 default "5"; 1040 description 1041 "The amount of time the resolver will wait for a 1042 response from each remote name server before 1043 retrying the query via a different name server."; 1044 } 1045 leaf attempts { 1046 type uint8 { 1047 range "1..max"; 1048 } 1049 default "2"; 1050 description 1051 "The number of times the resolver will send a query to 1052 all its name servers before giving up and returning an 1053 error to the calling application."; 1054 } 1055 } 1056 } 1058 container radius { 1059 if-feature radius; 1061 description 1062 "Configuration of the RADIUS client."; 1064 list server { 1065 key name; 1066 ordered-by user; 1067 description 1068 "List of RADIUS servers used by the device. 1070 When the RADIUS client is invoked by a calling 1071 application, it sends the query to the first server in 1072 this list. If no response has been received within 1073 'timeout' seconds, the client continues with the next 1074 server in the list. If no response is received from any 1075 server, the client continues with the first server again. 1076 When the client has traversed the list 'attempts' times 1077 without receiving any response, it gives up and returns an 1078 error to the calling application."; 1080 leaf name { 1081 type string; 1082 description 1083 "An arbitrary name for the RADIUS server."; 1085 } 1086 choice transport { 1087 mandatory true; 1088 description 1089 "The transport protocol specific parameters for this 1090 server."; 1092 case udp { 1093 container udp { 1094 description 1095 "Contains UDP specific configuration parameters 1096 for RADIUS."; 1097 leaf address { 1098 type inet:host; 1099 mandatory true; 1100 description 1101 "The address of the RADIUS server."; 1102 } 1103 leaf authentication-port { 1104 type inet:port-number; 1105 default "1812"; 1106 description 1107 "The port number of the RADIUS server."; 1108 } 1109 leaf shared-secret { 1110 type string; 1111 mandatory true; 1112 nacm:default-deny-all; 1113 description 1114 "The shared secret which is known to both the 1115 RADIUS client and server."; 1116 reference 1117 "RFC 2865: Remote Authentication Dial In User 1118 Service"; 1119 } 1120 } 1121 } 1122 } 1123 leaf authentication-type { 1124 type identityref { 1125 base radius-authentication-type; 1126 } 1127 default radius-pap; 1128 description 1129 "The authentication type requested from the RADIUS 1130 server."; 1131 } 1132 } 1133 container options { 1134 description 1135 "RADIUS client options."; 1137 leaf timeout { 1138 type uint8 { 1139 range "1..max"; 1140 } 1141 units "seconds"; 1142 default "5"; 1143 description 1144 "The number of seconds the device will wait for a 1145 response from each RADIUS server before trying with a 1146 different server."; 1147 } 1148 leaf attempts { 1149 type uint8 { 1150 range "1..max"; 1151 } 1152 default "2"; 1153 description 1154 "The number of times the device will send a query to 1155 all its RADIUS servers before giving up."; 1156 } 1157 } 1158 } 1160 container authentication { 1161 nacm:default-deny-write; 1162 if-feature authentication; 1164 description 1165 "The authentication configuration subtree."; 1167 leaf-list user-authentication-order { 1168 type identityref { 1169 base authentication-method; 1170 } 1171 must '(. != "sys:radius" or ../../radius/server)' { 1172 error-message 1173 "When 'radius' is used, a RADIUS server" 1174 + " must be configured."; 1175 description 1176 "When 'radius' is used as an authentication method, 1177 a RADIUS server must be configured."; 1178 } 1179 ordered-by user; 1180 description 1181 "When the device authenticates a user with a password, 1182 it tries the authentication methods in this leaf-list in 1183 order. If authentication with one method fails, the next 1184 method is used. If no method succeeds, the user is 1185 denied access. 1187 An empty user-authentication-order leaf-list still allows 1188 authentication of users using mechanisms that do not 1189 involve a password. 1191 If the 'radius-authentication' feature is advertised by 1192 the NETCONF server, the 'radius' identity can be added to 1193 this list. 1195 If the 'local-users' feature is advertised by the 1196 NETCONF server, the 'local-users' identity can be 1197 added to this list."; 1198 } 1200 list user { 1201 if-feature local-users; 1202 key name; 1203 description 1204 "The list of local users configured on this device."; 1206 leaf name { 1207 type string; 1208 description 1209 "The user name string identifying this entry."; 1210 } 1211 leaf password { 1212 type ianach:crypt-hash; 1213 description 1214 "The password for this entry."; 1215 } 1216 list authorized-key { 1217 key name; 1218 description 1219 "A list of public SSH keys for this user. These keys 1220 are allowed for SSH authentication, as described in 1221 RFC 4253."; 1222 reference 1223 "RFC 4253: The Secure Shell (SSH) Transport Layer 1224 Protocol"; 1226 leaf name { 1227 type string; 1228 description 1229 "An arbitrary name for the SSH key."; 1230 } 1231 leaf algorithm { 1232 type string; 1233 mandatory true; 1234 description 1235 "The public key algorithm name for this SSH key. 1237 Valid values are the values in the IANA Secure Shell 1238 (SSH) Protocol Parameters registry, Public Key 1239 Algorithm Names"; 1240 reference 1241 "IANA Secure Shell (SSH) Protocol Parameters registry, 1242 Public Key Algorithm Names"; 1243 } 1244 leaf key-data { 1245 type binary; 1246 mandatory true; 1247 description 1248 "The binary public key data for this SSH key, as 1249 specified by RFC 4253, Section 6.6, i.e.,: 1251 string certificate or public key format 1252 identifier 1253 byte[n] key/certificate data 1254 "; 1255 reference 1256 "RFC 4253: The Secure Shell (SSH) Transport Layer 1257 Protocol"; 1258 } 1259 } 1260 } 1261 } 1262 } 1264 /* 1265 * Operational state data nodes 1266 */ 1268 container system-state { 1269 config false; 1270 description 1271 "System group operational state."; 1273 container platform { 1274 description 1275 "Contains vendor-specific information for 1276 identifying the system platform and operating system."; 1277 reference 1278 "IEEE Std 1003.1-2008 - sys/utsname.h"; 1280 leaf os-name { 1281 type string; 1282 description 1283 "The name of the operating system in use, 1284 for example 'Linux'"; 1285 reference 1286 "IEEE Std 1003.1-2008 - utsname.sysname"; 1287 } 1288 leaf os-release { 1289 type string; 1290 description 1291 "The current release level of the operating 1292 system in use. This string MAY indicate 1293 the OS source code revision."; 1294 reference 1295 "IEEE Std 1003.1-2008 - utsname.release"; 1296 } 1297 leaf os-version { 1298 type string; 1299 description 1300 "The current version level of the operating 1301 system in use. This string MAY indicate 1302 the specific OS build date and target variant 1303 information."; 1304 reference 1305 "IEEE Std 1003.1-2008 - utsname.version"; 1306 } 1307 leaf machine { 1308 type string; 1309 description 1310 "A vendor-specific identifier string representing 1311 the hardware in use."; 1312 reference 1313 "IEEE Std 1003.1-2008 - utsname.machine"; 1314 } 1315 } 1317 container clock { 1318 description 1319 "Monitoring of the system 1320 date and time properties."; 1322 leaf current-datetime { 1323 type yang:date-and-time; 1324 description 1325 "The current system date and time."; 1326 } 1327 leaf boot-datetime { 1328 type yang:date-and-time; 1329 description 1330 "The system date and time when the system last restarted."; 1331 } 1332 } 1333 } 1335 rpc set-current-datetime { 1336 nacm:default-deny-all; 1337 description 1338 "Set the /system-state/clock/current-datetime leaf 1339 to the specified value. 1341 If the system is using NTP (i.e., /system/ntp/enabled 1342 is set to 'true'), then this operation will 1343 fail with error-tag 'operation-failed', 1344 and error-app-tag value of 'ntp-active'"; 1345 input { 1346 leaf current-datetime { 1347 type yang:date-and-time; 1348 mandatory true; 1349 description 1350 "The current system date and time."; 1351 } 1352 } 1353 } 1355 rpc system-restart { 1356 nacm:default-deny-all; 1357 description 1358 "Request that the entire system be restarted immediately. 1359 A server SHOULD send an rpc reply to the client before 1360 restarting the system."; 1361 } 1363 rpc system-shutdown { 1364 nacm:default-deny-all; 1365 description 1366 "Request that the entire system be shut down immediately. 1367 A server SHOULD send an rpc reply to the client before 1368 shutting down the system."; 1369 } 1371 } 1372 1374 7. IANA Considerations 1376 IANA is requested to create an IANA-maintained YANG Module called 1377 "iana-crypt-hash", based on the contents of Section 5, which will 1378 allow for new hash algorithms to be added to the type "crypt-hash". 1379 The registration procedure will be Expert Review, as defined by 1380 [RFC5226]. 1382 This document registers two URIs in the IETF XML registry [RFC3688]. 1383 Following the format in RFC 3688, the following registrations are 1384 requested to be made. 1386 URI: urn:ietf:params:xml:ns:yang:iana-crypt-hash 1387 Registrant Contact: The IESG. 1388 XML: N/A, the requested URI is an XML namespace. 1390 URI: urn:ietf:params:xml:ns:yang:ietf-system 1391 Registrant Contact: The IESG. 1392 XML: N/A, the requested URI is an XML namespace. 1394 This document registers two YANG modules in the YANG Module Names 1395 registry [RFC6020]. 1397 name: iana-crypt-hash 1398 namespace: urn:ietf:params:xml:ns:yang:iana-crypt-hash 1399 prefix: ianach 1400 reference: RFC XXXX 1402 name: ietf-system 1403 namespace: urn:ietf:params:xml:ns:yang:ietf-system 1404 prefix: sys 1405 reference: RFC XXXX 1407 8. Security Considerations 1409 The YANG modules defined in this memo are designed to be accessed via 1410 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1411 secure transport layer and the mandatory-to-implement secure 1412 transport is SSH [RFC6242]. Authorization for access to specific 1413 portions of conceptual data and operations within this module is 1414 provided by the NETCONF access control model (NACM) [RFC6536]. 1416 There are a number of data nodes defined in the "ietf-system" YANG 1417 module which are writable/creatable/deletable (i.e., config true, 1418 which is the default). These data nodes may be considered sensitive 1419 or vulnerable in some network environments. Write operations to 1420 these data nodes can have a negative effect on network operations. 1421 It is thus important to control write access (e.g., via edit-config) 1422 to these data nodes. These are the subtrees and data nodes and their 1423 sensitivity/vulnerability: 1425 o /system/clock/timezone: This choice contains the objects used to 1426 control the timezone used by the device. 1428 o /system/ntp: This container contains the objects used to control 1429 the Network Time Protocol servers used by the device. 1431 o /system/dns-resolver: This container contains the objects used to 1432 control the Domain Name System servers used by the device. 1434 o /system/radius: This container contains the objects used to 1435 control the Remote Authentication Dial-In User Service servers 1436 used by the device. 1438 o /system/authentication/user-authentication-order: This leaf 1439 controls how user login attempts are authenticated by the device. 1441 o /system/authentication/user: This list contains the local users 1442 enabled on the system. 1444 Some of the readable data nodes in the "ietf-system" YANG module may 1445 be considered sensitive or vulnerable in some network environments. 1446 It is thus important to control read access (e.g., via get, get- 1447 config, or notification) to these data nodes. These are the subtrees 1448 and data nodes and their sensitivity/vulnerability: 1450 o /system/platform: This container has objects which may help 1451 identify the specific NETCONF server and/or operating system 1452 implementation used on the device. 1454 o /system/authentication/user: This list has objects that may help 1455 identify the specific user names and password information in use 1456 on the device. 1458 Some of the remote procedure call (RPC) operations in the 1459 "ietf-system" YANG module may be considered sensitive or vulnerable 1460 in some network environments. It is thus important to control access 1461 to these operations. These are the operations and their sensitivity/ 1462 vulnerability: 1464 o set-current-datetime: Changes the current date and time on the 1465 device. 1467 o system-restart: Reboots the device. 1469 o system-shutdown: Shuts down the device. 1471 Since this document describes the use of RADIUS for purposes of 1472 authentication, it is vulnerable to all of the threats that are 1473 present in other RADIUS applications. For a discussion of such 1474 threats, see [RFC2865] and [RFC3162], and section 4 of [RFC3579]. 1476 This document provides configuration parameters for SSH's "publickey" 1477 and "password" authentication mechanisms. Section 9.4 of [RFC4251] 1478 and section 11 of [RFC4252] discuss security considerations for these 1479 mechanisms. 1481 The "iana-crypt-hash" YANG module defines a type "crypt-hash" that 1482 can be used to store MD5 hashes. [RFC6151] discusses security 1483 considerations for MD5. The usage of MD5 is NOT RECOMMENDED. 1485 9. Change Log 1487 -- RFC Ed.: remove this section before publication. 1489 9.1. 00-01 1491 o added configuration-source identities 1493 o added configuration-source leaf to ntp and dns (via grouping) to 1494 choose configuration source 1496 o added association-type, iburst, prefer, and true leafs to the ntp- 1497 server list 1499 o extended the ssh keys for a user to a list of keys. support all 1500 defined key algorithms, not just dsa and rsa 1502 o clarified timezone-utc-offset description-stmt 1504 o removed '/system/ntp/server/true' leaf from data model 1506 9.2. 01-02 1508 o added default-stmts to ntp-server/iburst and ntp-server/prefer 1509 leafs 1511 o changed timezone-location leaf to use iana-timezone typedef 1512 instead of a string 1514 9.3. 02-03 1516 o removed configuration-source identities and leafs 1518 9.4. 03-04 1520 o removed ndots dns resolver option 1522 o added radius-authentication-type identity, and identities for pap 1523 and chap, and a leaf to control which authentication type to use 1524 when communicating with the radius server 1526 o made 0 an invalid value for timeouts and attempts 1528 9.5. 04-05 1530 o updated tree diagram explanation text 1532 9.6. 05-06 1534 o changed ntp/use-ntp to ntp/enabled 1536 o changed ntp/ntp-server to ntp/server 1538 o removed /system/platform/nodename leaf 1540 o changed /system/name to /system/hostname 1542 o simplified must expression in user-authentication-order 1544 o added optional rounds to sha hash definition 1546 o clarified the crypt-hash description 1548 o clarified ntp descriptions 1550 o clarified YANG module description to indicate that some system 1551 properties are supported, not the entire system 1553 o clarified that system identification values are vendor specific, 1554 not the data node objects 1556 o clarified sec. 2.2 and 2.3 to indicate that the server should also 1557 be capable of configuring these properties 1559 o changed /system/dns/search from inet:host to inet:domain-name 1561 o changed RFC6021 reference to 6021-bis 1563 o changed /system/platform/nodename to /system/platform/hostname 1565 o changed /system/radius/server/{leafs} to be within a choice and 1566 'udp' case statement so other transport specific parameters can 1567 augment this list or they can be added by the WG to a future 1568 version of this module. {leafs} are authentication-port and 1569 shared-secret. 1571 o updated YANG tree diagrams for objects added in -05 and -06 1573 9.7. 06-07 1575 o updated the Abstract and Introduction 1577 o updated Tree diagram notation 1578 o identify all external servers (dns, ntp, radius) by name instead 1579 of address, in order to make the data model extensible for 1580 additional transport protocol. 1582 o updated the Security Considerations section with a reference to 1583 NACM. 1585 9.8. 07-08 1587 o renamed the DNS transport to 'udp-and-tcp' and added references. 1589 o moved the operational state nodes into /system-state. 1591 9.9. 08-09 1593 o made "ntp" node a presence container 1595 o added reference to RFC 6151 1597 o updated reference from 6021-bis to RFC 6991 1599 o cleaned up usage of config false in the YANG module 1601 9.10. 09-10 1603 o clarified relationship with SNMPv2-MIB 1605 9.11. 11-12 1607 o added typedef "timezone-name", and removed reference to 1608 draft-ietf-netmod-iana-timezones 1610 9.12. 13-14 1612 o moved the "crypt-hash" typedef to an IANA maintained module. 1614 o updated security considerations to mention RADIUS threats. 1616 9.13. 14-15 1618 o updated security considerations to mention SSH authentication 1619 method threats. 1621 10. References 1623 10.1. Normative References 1625 [FIPS.180-3.2008] 1626 National Institute of Standards and Technology, "Secure 1627 Hash Standard", FIPS PUB 180-3, October 2008, . 1631 [IEEE-1003.1-2008] 1632 Institute of Electrical and Electronics Engineers, 1633 "POSIX.1-2008", IEEE Standard 1003.1, March 2008. 1635 [RFC1035] Mockapetris, P., "Domain names - implementation and 1636 specification", STD 13, RFC 1035, November 1987. 1638 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1639 April 1992. 1641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1642 Requirement Levels", BCP 14, RFC 2119, March 1997. 1644 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1645 "Remote Authentication Dial In User Service (RADIUS)", 1646 RFC 2865, June 2000. 1648 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1649 RFC 3162, August 2001. 1651 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1652 Simple Network Management Protocol (SNMP)", STD 62, 1653 RFC 3418, December 2002. 1655 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1656 Protocol Architecture", RFC 4251, January 2006. 1658 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1659 Authentication Protocol", RFC 4252, January 2006. 1661 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1662 Transport Layer Protocol", RFC 4253, January 2006. 1664 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1665 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1666 May 2008. 1668 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 1669 User Service (RADIUS) Authorization for Network Access 1670 Server (NAS) Management", RFC 5607, July 2009. 1672 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 1673 Requirements", RFC 5966, August 2010. 1675 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1676 Network Configuration Protocol (NETCONF)", RFC 6020, 1677 October 2010. 1679 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1680 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1681 RFC 6151, March 2011. 1683 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1684 and A. Bierman, Ed., "Network Configuration Protocol 1685 (NETCONF)", RFC 6241, June 2011. 1687 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1688 Shell (SSH)", RFC 6242, June 2011. 1690 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1691 Protocol (NETCONF) Access Control Model", RFC 6536, 1692 March 2012. 1694 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1695 July 2013. 1697 10.2. Informative References 1699 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1700 Dial In User Service) Support For Extensible 1701 Authentication Protocol (EAP)", RFC 3579, September 2003. 1703 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1704 January 2004. 1706 [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the 1707 Time Zone Database", BCP 175, RFC 6557, February 2012. 1709 Authors' Addresses 1711 Andy Bierman 1712 YumaWorks 1714 Email: andy@yumaworks.com 1716 Martin Bjorklund 1717 Tail-f Systems 1719 Email: mbj@tail-f.com