idnits 2.17.1 draft-ietf-radext-management-authorization-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 31, 2009) is 5437 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) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) -- Obsolete informational reference (is this intentional?): RFC 4742 (Obsoleted by RFC 6242) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Nelson 3 Internet-Draft Elbrys Networks, Inc. 4 Intended status: Standards Track G. Weber 5 Expires: December 2, 2009 Individual Contributor 6 May 31, 2009 8 Remote Authentication Dial-In User Service (RADIUS) Authorization for 9 Network Access Server (NAS) Management 10 draft-ietf-radext-management-authorization-07.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on December 2, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document specifies Remote Authentication Dial-In User Service 59 (RADIUS) attributes for authorizing management access to a Network 60 Access Server (NAS). Both local and remote management are supported, 61 with granular access rights and management privileges. Specific 62 provisions are made for remote management via framed management 63 protocols, and for management access over a secure transport 64 protocol. 66 Table of Contents 68 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Domain of Applicability . . . . . . . . . . . . . . . . . . . 5 72 5. New Values for Existing RADIUS Attributes . . . . . . . . . . 6 73 5.1. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 6 74 6. New RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 6 75 6.1. Framed-Management-Protocol . . . . . . . . . . . . . . . . 6 76 6.2. Management-Transport-Protection . . . . . . . . . . . . . 9 77 6.3. Management-Policy-Id . . . . . . . . . . . . . . . . . . . 12 78 6.4. Management-Privilege-Level . . . . . . . . . . . . . . . . 13 79 7. Use with Dynamic Authorization . . . . . . . . . . . . . . . . 15 80 8. Examples of attribute groupings . . . . . . . . . . . . . . . 15 81 9. Diameter Translation Considerations . . . . . . . . . . . . . 17 82 10. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 18 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 85 12.1. General Considerations . . . . . . . . . . . . . . . . . . 20 86 12.2. RADIUS Proxy Operation Considerations . . . . . . . . . . 21 87 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22 90 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 93 1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 This document uses terminology from RFC 2865 [RFC2865], RFC 2866 100 [RFC2866] and RFC 5176 [RFC5176]. 102 The term "integrity protection", as used in this document, is *not* 103 the same as "authentication", as used in SNMP. Integrity protection 104 requires the sharing of cryptographic keys, but it does not require 105 authenticated principals. Integrity protection could be used, for 106 example, with anonymous Diffie-Hellman key agreement. In SNMP, the 107 proof of identity of the principals (authentication) is conflated 108 with tamper-resistance of the protected messages (integrity). In 109 this document, we assume that integrity protection and authentication 110 are separate concerns. Authentication is part of the base RADIUS 111 protocol. 113 SNMP uses the terms "auth" and "noAuth", as well as "priv" and 114 "noPriv". There is no analog to auth or noAuth in this document. In 115 this document, we are assuming that authentication always occurs when 116 it is required, i.e. as a prerequisite to provisioning of access via 117 an Access-Accept packet. 119 2. Introduction 121 RFC 2865 [RFC2865] defines the NAS-Prompt (7) and Administrative (6) 122 values of the Service-Type (6) Attribute. Both of these values 123 provide access to the interactive, text-based Command Line Interface 124 (CLI) of the NAS, and were originally developed to control access to 125 the physical console port of the NAS, most often a serial port. 127 Remote access to the CLI of the NAS has been available in NAS 128 implementations for many years, using protocols such as Telnet, 129 Rlogin and the remote terminal service of the Secure SHell (SSH). In 130 order to distinguish local, physical, console access from remote 131 access, the NAS-Port-Type (61) Attribute is generally included in 132 Access-Request and Access-Accept messages, along with the Service- 133 Type (6) Attribute, to indicate the form of access. A NAS-Port-Type 134 (61) Attribute with a value of of Async (0) is used to signify a 135 local serial port connection, while a value of Virtual (5) is used to 136 signify a remote connection, via a remote terminal protocol. This 137 usage provides no selectivity among the various available remote 138 terminal protocols (e.g. Telnet, Rlogin, SSH, etc.). 140 Today, it is common for network devices to support more than the two 141 privilege levels for management access provided by the Service-Type 142 (6) Attribute with values of NAS-Prompt (7) (non-privileged) and 143 Administrative (6) (privileged). Also, other management mechanisms 144 may be used, such as Web-based management, Simple Network Management 145 Protocol (SNMP) and NETCONF. To provide support for these additional 146 features, this specification defines attributes for Framed Management 147 protocols, management protocol security, and management access 148 privilege levels. 150 Remote management via the command line is carried over protocols such 151 as Telnet, Rlogin and the remote terminal service of SSH. Since 152 these protocols are primarily for the delivery of terminal or pseudo- 153 TTY services, the term "Framed Management" is used to describe 154 management protocols supporting techniques other than the command- 155 line. Typically these mechanisms format management information in a 156 binary or textual encoding such as HTML, XML or ASN.1/BER. Examples 157 include Web-based management (HTML over HTTP or HTTPS), NETCONF (XML 158 over SSH or BEEP or SOAP) and SNMP (SMI over ASN.1/BER). Command 159 line interface, menu interface or other text-based (e.g. ASCII or 160 UTF-8) terminal emulation services are not considered to be Framed 161 Management protocols. 163 3. Overview 165 To support the authorization and provisioning of Framed Management 166 access to managed entities, this document introduces a new value for 167 the Service-Type (6) Attribute [RFC2865], and one new attribute. The 168 new value for the Service-Type (6) Attribute is Framed-Management 169 (TBA-1), used for remote device management via a Framed Management 170 protocol. The new attribute is Framed-Management-Protocol (TBA-2), 171 the value of which specifies a particular protocol for use in the 172 remote management session. 174 Two new attributes are introduced in this document in support of 175 granular management access rights or command privilege levels. The 176 Management-Policy-Id (TBA-4) Attribute provides a text string 177 specifying a policy name of local scope, that is assumed to have been 178 pre-provisioned on the NAS. This use of an attribute to specify use 179 of a pre-provisioned policy is similar to the Filter-Id (11) 180 Attribute defined in [RFC2865] Section 5.11. 182 The local application of the Management-Policy-Id (TBA-4) Attribute 183 within the managed entity may take the form of (a) one of an 184 enumeration of command privilege levels, (b) a mapping into an SNMP 185 Access Control Model, such as the View Based Access Control Model 186 (VACM) [RFC3415], or (c) some other set of management access policy 187 rules that is mutually understood by the managed entity and the 188 remote management application. Examples are given in Section 8. 190 The Management-Privilege-Level (TBA-5) Attribute contains an integer- 191 valued management privilege level indication. This attribute serves 192 to modify or augment the management permissions provided by the NAS- 193 Prompt (7) value of the Service-Type (6) Attribute, and thus applies 194 to CLI management. 196 To enable management security requirements to be specified, the 197 Management-Transport-Protection (TBA-3) Attribute is introduced. The 198 value of this attribute indicates the minimum level of secure 199 transport protocol protection required for the provisioning of NAS- 200 Prompt (7), Administrative (6) or Framed-Management (TBA-1) service. 202 4. Domain of Applicability 204 Most of the RADIUS Attributes defined in this document have broad 205 applicability for provisioning local and remote management access to 206 NAS devices. However, those attributes that provision remote access 207 over framed management protocols and over secure transports have 208 special considerations. This document does not specify details of 209 the integration of these protocols with a RADIUS client in the NAS 210 implementation. However, there are functional requirements for 211 correct application of framed management protocols and/or secure 212 transport protocols that will limit the selection of such protocols 213 that can be considered for use with RADIUS. Since the RADIUS user 214 credentials are typically obtained by the RADIUS client from the 215 secure transport protocol server or the framed management protocol 216 server, the protocol, and its implementation in the NAS, MUST support 217 forms of credentials that are compatible with the authentication 218 methods supported by RADIUS. 220 RADIUS currently supports the following user authentication methods, 221 although others may be added in the future: 223 o Password (RFC 2865) 224 o CHAP (RFC 2865) 225 o ARAP (RFC 2869) 226 o EAP (RFC 2869, RFC 3579) 227 o HTTP Digest (RFC 5090) 229 The remote management protocols selected for use the RADIUS remote 230 NAS management sessions, for example those described in Section 6.1, 231 and the secure transport protocols selected to meet the protection 232 requirements, as described in Section 6.2, obviously need to support 233 user authentication methods that are compatible with those that exist 234 in RADIUS. The RADIUS authentication methods most likely usable with 235 these protocols are Password, CHAP and possibly HTTP Digest, with 236 Password being the distinct common denominator. There are many 237 secure transports that support other, more robust, authentication 238 mechanisms, such as public key. RADIUS has no support for public key 239 authentication, except within the context of an EAP Method. The 240 applicability statement for EAP indicates that it is not intended for 241 use as an application-layer authentication mechanism, so its use with 242 the mechanisms described in this document is NOT RECOMMENDED. In 243 some cases, Password may be the only compatible RADIUS authentication 244 method available. 246 5. New Values for Existing RADIUS Attributes 248 5.1. Service-Type 250 The Service-Type (6) Attribute is defined in Section 5.6 of RFC 2865 251 [RFC2865]. This document defines a new value of the Service-Type 252 Attribute, as follows: 254 (TBA-1) Framed-Management 256 The semantics of the Framed-Management service are as follows: 258 Framed-Management A framed management protocol session should 259 be started on the NAS. 261 6. New RADIUS Attributes 263 This document defines four new RADIUS attributes related to 264 management authorization. 266 6.1. Framed-Management-Protocol 268 The Framed-Management-Protocol (TBA-2) Attribute indicates the 269 application-layer management protocol to be used for Framed 270 Management access. It MAY be used in both Access-Request and Access- 271 Accept packets. This attribute is used in conjunction with a 272 Service-Type (6) Attribute with the value of Framed-Management 273 (TBA-1). 275 It is RECOMMENDED that the NAS include an appropriately valued 276 Framed-Management-Protocol (TBA-2) Attribute in an Access-Request 277 packet, indicating the type of management access being requested. It 278 is further RECOMMENDED that the NAS include a Service-Type (6) 279 Attribute with the value Framed-Management (TBA-1) in the same 280 Access-Request packet. The RADIUS server MAY use these attributes as 281 a hint in making its authorization decision. 283 The RADIUS server MAY include a Framed-Management-Protocol (TBA-2) 284 Attribute in an Access-Accept packet that also includes a Service- 285 Type (6) Attribute with a value of Framed-Management (TBA-1), when 286 the RADIUS Server chooses to enforce a management access policy for 287 the authenticated user that dictates one form of management access in 288 preference to others. 290 When a NAS receives a Framed-Management-Protocol (TBA-2) Attribute in 291 an Access-Accept packet, it MUST deliver that specified form of 292 management access or disconnect the session. If the NAS does not 293 support the provisioned management application-layer protocol, or the 294 management access protocol requested by the user does not match that 295 of the Framed-Management-Protocol (TBA-2) Attribute in the Access- 296 Accept packet, the NAS MUST treat the Access-Accept packet as if it 297 had been an Access-Reject. 299 A summary of the Framed-Management-Protocol (TBA-2) Attribute format 300 is shown below. The fields are transmitted from left to right. 302 0 1 2 3 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type | Length | Value 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Value (cont) | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Type 312 (TBA-2) for Framed-Management-Protocol. 314 Length 316 6 318 Value 320 The Value field is a four octet enumerated value. 322 1 SNMP 323 2 Web-based 324 3 NETCONF 325 4 FTP 326 5 TFTP 327 6 SFTP 328 7 RCP 329 8 SCP 331 All other values are reserved for IANA allocation subject to the 332 provisions of Section 11. 334 The acronyms used in the above table expand as follows: 336 o SNMP: Simple Network Management Protocol. [RFC3411], [RFC3412], 337 [RFC3413], [RFC3414], [RFC3415], [RFC3416], [RFC3417], [RFC3418] 339 o Web-based: Use of an embedded web server in the NAS for management 340 via a generic web browser client. The interface presented to the 341 administrator may be graphical, tabular or textual. The protocol 342 is HTML over HTTP. The protocol may optionally be HTML over 343 HTTPS, i.e. using HTTP over TLS. [HTML] [RFC2616] 345 o NETCONF: Management via the NETCONF protocol using XML over 346 supported transports (e.g. SSH, BEEP, SOAP). As secure transport 347 profiles are defined for NETCONF, the list of transport options 348 may expand. [RFC4741], [RFC4742], [RFC4743], [RFC4744] 350 o FTP: File Transfer Protocol, used to transfer configuration files 351 to and from the NAS. [RFC0959] 353 o TFTP: Trivial File Transfer Protocol, used to transfer 354 configuration files to and from the NAS. [RFC1350] 356 o SFTP: SSH File Transfer Protocol, used to securely transfer 357 configuration files to and from the NAS. SFTP uses the services 358 of SSH. [SFTP] See also Section 3.7, "SSH and File Transfers" of 359 [SSH]. Additional information on the "sftp" program may typically 360 be found in the online documentation ("man" pages) of Unix 361 systems. 363 o RCP: Remote CoPy file copy utility (Unix-based), used to transfer 364 configuration files to and from the NAS. See Section 3.7, "SSH 365 and File Transfers" of [SSH]. Additional information on the "rcp" 366 program may typically be found in the online documentation ("man" 367 pages) of Unix systems. 369 o SCP: Secure CoPy file copy utility (Unix-based), used to transfer 370 configuration files to and from the NAS. The "scp" program is a 371 simple wrapper around SSH. It's basically a patched BSD Unix 372 "rcp" which uses ssh to do the data transfer (instead of using 373 "rcmd"). See Section 3.7, "SSH and File Transfers" of [SSH]. 374 Additional information on the "scp" program may typically be found 375 in the online documentation ("man" pages) of Unix systems. 377 6.2. Management-Transport-Protection 379 The Management-Transport-Protection (TBA-3) Attribute specifies the 380 minimum level of protection that is required for a protected 381 transport used with the framed or non-framed management access 382 session. The protected transport used by the NAS MAY provide a 383 greater level of protection, but MUST NOT provide a lower level of 384 protection. 386 When a secure form of non-framed management access is specified, it 387 means that the remote terminal session is encapsulated in some form 388 of protected transport, or tunnel. It may also mean that an explicit 389 secure mode of operation is required, when the framed management 390 protocol contains an intrinsic secure mode of operation. The 391 Management-Transport-Protection (TBA-3) Attribute does not apply to 392 CLI access via a local serial port, or other non-remote connection. 394 When a secure form of Framed Management access is specified, it means 395 that the application-layer management protocol is encapsulated in 396 some form of protected transport, or tunnel. It may also mean that 397 an explicit secure mode of operation is required, when the Framed 398 Management protocol contains an intrinsic secure mode of operation. 400 A value of "No Protection (1)" indicates that a secure transport 401 protocol is not required, and that the NAS SHOULD accept a connection 402 over any transport associated with the application-layer management 403 protocol. The definitions of management application to transport 404 bindings are defined in the relevant documents that specify those 405 management application protocols. The same "No Protection" semantics 406 are conveyed by omitting this attribute from an Access-Accept packet. 408 Specific protected transport protocols, cipher suites, key agreement 409 methods, or authentication methods are not specified by this 410 attribute. Such provisioning is beyond the scope of this document. 412 It is RECOMMENDED that the NAS include an appropriately valued 413 Management-Transport-Protection (TBA-3) Attribute in an Access- 414 Request packet, indicating the level of transport protection for the 415 management access being requested, when that information is available 416 to the RADIUS client. The RADIUS server MAY use this attribute as a 417 hint in making its authorization decision. 419 The RADIUS server MAY include a Management-Transport-Protection 420 (TBA-3) Attribute in an Access-Accept packet that also includes a 421 Service-Type (6) Attribute with a value of Framed-Management (TBA-1), 422 when the RADIUS Server chooses to enforce an management access 423 security policy for the authenticated user that dictates a minimum 424 level of transport security. 426 When a NAS receives a Management-Transport-Protection (TBA-3) 427 Attribute in an Access-Accept packet, it MUST deliver the management 428 access over a transport with equal or better protection 429 characteristics or disconnect the session. If the NAS does not 430 support protected management transport protocols, or the level of 431 protection available does not match that of the Management-Transport- 432 Protection (TBA-3) Attribute in the Access-Accept packet, the NAS 433 MUST treat the response packet as if it had been an Access-Reject. 435 A summary of the Management-Transport-Protection (TBA-3) Attribute 436 format is shown below. The fields are transmitted from left to 437 right. 439 0 1 2 3 440 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type | Length | Value 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Value (cont) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Type 449 (TBA-3) for Management-Transport-Protection. 451 Length 453 6 455 Value 457 The Value field is a four octet enumerated value. 459 1 No-Protection 460 2 Integrity-Protection 461 3 Integrity-Confidentiality-Protection 463 All other values are reserved for IANA allocation subject to the 464 provisions of Section 11. 466 The names used in the above table are elaborated as follows: 468 o No-Protection: No transport protection is required. Accept 469 connections via any supported transport. 471 o Integrity-Protection: The management transport MUST provide 472 Integrity Protection, i.e. protection from unauthorized 473 modification, using a cryptographic checksum. 475 o Integrity-Confidentiality-Protection: The management transport 476 MUST provide both Integrity Protection and Confidentiality 477 Protection, i.e. protection from unauthorized modification, using 478 a cryptographic checksum, and protection from unauthorized 479 disclosure, using encryption. 481 The configuration or negotiation of acceptable algorithms, modes and 482 credentials for the cryptographic protection mechanisms used in 483 implementing protected management transports is outside the scope of 484 this document. Many such mechanisms have standardized methods of 485 configuration and key management. 487 6.3. Management-Policy-Id 489 The Management-Policy-Id (TBA-4) Attribute indicates the name of the 490 management access policy for this user. Zero or one Management- 491 Policy-Id (TBA-4) Attributes MAY be sent in an Access-Accept packet. 492 Identifying a policy by name allows the policy to be used on 493 different NASes without regard to implementation details. 495 Multiple forms of management access rules may be expressed by the 496 underlying named policy, the definition of which is beyond the scope 497 of this document. The management access policy MAY be applied 498 contextually, based on the nature of the management access method. 499 For example, some named policies may only be valid for application to 500 NAS-Prompt (7) services and some other policies may only be valid for 501 SNMP. 503 The management access policy named in this attribute, received in an 504 Access-Accept packet, MUST be applied to the session authorized by 505 the Access-Accept. If the NAS supports this attribute, but the 506 policy name is unknown, or if the RADIUS client is able to determine 507 that the policy rules are incorrectly formatted, the NAS MUST treat 508 the Access-Accept packet as if it had been an Access-Reject. 510 No precedence relationship is defined for multiple occurrences of the 511 Management-Policy-Id (TBA-4) Attribute. NAS behavior in such cases 512 is undefined. Therefore, two or more occurrences of this attribute 513 SHOULD NOT be included in an Access-Accept or CoA-Request. In the 514 absence of further specification defining some sort of precedence 515 relationship, it is not possible to guarantee multi-vendor 516 interoperability when using multiple instances of this attribute in a 517 single Access-Accept or CoA-Request packet. 519 The content of the Management-Policy-Id (TBA-4) Attribute is expected 520 to be the name of a management access policy of local significance to 521 the NAS, within a namespace of significance to the NAS. In this 522 regard, the behavior is similar to that for the Filter-Id (11) 523 Attribute. The policy names and rules are committed to the local 524 configuration data-store of the NAS, and are provisioned by means 525 beyond the scope of this document, such as via SNMP, NETCONF or CLI. 527 The namespace used in the Management-Policy-Id (TBA-4) Attribute is 528 simple and monolithic. There is no explicit or implicit structure or 529 hierarchy . For example, in the text string "example.com", the "." 530 (period or dot) is just another character. It is expected that text 531 string matching will be performed without parsing the text string 532 into any sub-fields. 534 Overloading or subdividing this simple name with multi-part 535 specifiers (e.g. Access=remote, Level=7) is likely to lead to poor 536 multi-vendor interoperability and SHOULD NOT be utilized. If a 537 simple, unstructured policy name is not sufficient, it is RECOMMENDED 538 that a Vendor Specific (26) Attribute be used instead, rather than 539 overloading the semantics of Management-Policy-Id. 541 A summary of the Management-Policy-Id (TBA-4) Attribute format is 542 shown below. The fields are transmitted from left to right. 544 0 1 2 545 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 547 | Type | Length | Text ... 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 550 Type 552 (TBA-4) for Management-Policy-Id. 554 Length 556 >= 3 558 Text 560 The Text field is one or more octets, and its contents are 561 implementation dependent. It is intended to be human readable and 562 the contents MUST NOT be parsed by the receiver; the contents can 563 only be used to look up locally defined policies. It is RECOMMENDED 564 that the message contain UTF-8 encoded 10646 [RFC3629] characters. 566 6.4. Management-Privilege-Level 568 The Management-Privilege-Level (TBA-5) Attribute indicates the 569 integer-valued privilege level to be assigned for management access 570 for the authenticated user. Many NASes provide the notion of 571 differentiated management privilege levels denoted by an integer 572 value. The specific access rights conferred by each value are 573 implementation dependent. It MAY be used in both Access-Request and 574 Access-Accept packets. 576 The mapping of integer values for this attribute to specific 577 collections of management access rights or permissions on the NAS is 578 vendor and implementation specific. Such mapping is often a user 579 configurable feature. It's RECOMMENDED that greater numeric values 580 imply greater privilege. However, it would be a mistake to assume 581 that this recommendation always holds. 583 The management access level indicated in this attribute, received in 584 an Access-Accept packet, MUST be applied to the session authorized by 585 the Access-Accept. If the NAS supports this attribute, but the 586 privilege level is unknown, the NAS MUST treat the Access-Accept 587 packet as if it had been an Access-Reject. 589 A summary of the Management-Privilege-Level (TBA-5) Attribute format 590 is show below. The fields are transmitted from left to right. 592 0 1 2 3 593 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type | Length | Value 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Value (cont) | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Type 602 (TBA-5) for Management-Privilege-Level. 604 Length 606 6 608 Value 610 The Value field is a four octet Integer, denoting a management 611 privilege level. 613 It is RECOMMENDED to limit use of the Management-Privilege-Level 614 (TBA-5) Attribute to sessions where the Service-Type (6) Attribute 615 has a value of NAS-Prompt (7) (not Administrative). Typically, NASes 616 treat NAS-Prompt as the minimal privilege CLI service and 617 Administrative as full privilege. Using the Management-Privilege- 618 Level (TBA-5) Attribute with a Service-Type (6) Attribute having a 619 value of NAS-Prompt (7) will have the effect of increasing the 620 minimum privilege level. Conversely, it is NOT RECOMMENDED to use 621 this attribute with a Service-Type (6) Attribute with a value of of 622 Administrative (6), which may require decreasing the maximum 623 privilege level. 625 It is NOT RECOMMENDED to use the Management-Privilege-Level (TBA-5) 626 Attribute in combination with a Management-Policy-Id (TBA-4) 627 Attribute or for management access methods other than interactive 628 CLI. The behavior resulting from such an overlay of management 629 access control provisioning is not defined by this document, and in 630 the absence of further specification is likely to lead to unexpected 631 behaviors, especially in multi-vendor environments. 633 7. Use with Dynamic Authorization 635 It is entirely OPTIONAL for the NAS management authorization 636 attributes specified in this document to be used in conjunction with 637 Dynamic Authorization extensions to RADIUS [RFC5176]. When such 638 usage occurs, those attributes MAY be used as listed in the Table of 639 Attributes in Section 10. 641 Some guidance on how to identify existing management sessions on a 642 NAS for the purposes of Dynamic Authorization is useful. The primary 643 session identifiers SHOULD be User-Name (1) and Service-Type (6). To 644 accommodate instances when that information alone does not uniquely 645 identify a session, a NAS supporting Dynamic Authorization SHOULD 646 maintain one or more internal session identifiers that can be 647 represented as RADIUS Attributes. Examples of such attributes 648 include Acct-Session-Id (44), Acct-Multi-Session-Id (50), NAS-Port 649 (5) or NAS-Port-Id (87). In the case of a remote management session, 650 common identifier values might include things such as the remote IP 651 address and remote TCP port number, or the file descriptor value for 652 use with the open socket. Any such identifier is obviously transient 653 in nature, and implementations SHOULD take care to avoid and/or 654 properly handle duplicate or stale values. 656 In order for the session identification attributes to be available to 657 the Dynamic Authorization Client, a NAS supporting Dynamic 658 Authorization for management sessions SHOULD include those session 659 identification attributes in the Access-Request message for each such 660 session. Additional discussion of session identification attribute 661 usage may be found in Section 3 of [RFC5176]. 663 8. Examples of attribute groupings 665 1. Unprotected CLI access, via the local console, to the "super- 666 user" access level: 668 * Service-Type (6) = Administrative (6) 669 * NAS-Port-Type (61) = Async (0) 670 * Management-Transport-Protection (TBA-3) = No-Protection (1) 672 2. Unprotected CLI access, via a remote console, to the "super-user" 673 access level: 675 * Service-Type (6) = Administrative (6) 676 * NAS-Port-Type (61) = Virtual (5) 677 * Management-Transport-Protection (TBA-3) = No-Protection (1) 679 3. CLI access, via a fully-protected secure remote terminal service 680 to the non-privileged user access level: 682 * Service-Type (6) = NAS-Prompt (7) 683 * NAS-Port-Type (61) = Virtual (5) 684 * Management-Transport-Protection (TBA-3) = Integrity- 685 Confidentiality-Protection (3) 687 4. CLI access, via a fully-protected secure remote terminal service, 688 to a custom management access level, defined by a policy: 690 * Service-Type (6) = NAS-Prompt (7) 691 * NAS-Port-Type (61) = Virtual (5) 692 * Management-Transport-Protection (TBA-3) = Integrity- 693 Confidentiality-Protection (3) 694 * Management-Policy-Id (TBA-4) = "Network Administrator" 696 5. CLI access, via a fully-protected secure remote terminal service, 697 with a management privilege level of 15: 699 * Service-Type (6) = NAS-Prompt (7) 700 * NAS-Port-Type (61) = Virtual (5) 701 * Management-Transport-Protection (TBA-3) = Integrity- 702 Confidentiality-Protection (3) 703 * Management-Privilege-Level (TBA-5) = 15 705 6. SNMP access, using an Access Control Model specifier, such as a 706 custom VACM View, defined by a policy: 708 * Service-Type (6) = Framed-Management (TBA-1) 709 * NAS-Port-Type (61) = Virtual (5) 710 * Framed-Management-Protocol (TBA-2) = SNMP (1) 711 * Management-Policy-Id (TBA-4) = "SNMP Network Administrator 712 View" 714 There is currently no standardized way of implementing this 715 management policy mapping within SNMP. Such mechanisms are the 716 topic of current research. 718 7. SNMP fully-protected access: 720 * Service-Type (6) = Framed-Management (TBA-1) 721 * NAS-Port-Type (61) = Virtual (5) 722 * Framed-Management-Protocol (TBA-2) = SNMP (1) 723 * Management-Transport-Protection (TBA-3) = Integrity- 724 Confidentiality-Protection (3) 726 8. Web (HTTP/HTML) access: 728 * Service-Type (6) = Framed-Management (TBA-1) 729 * NAS-Port-Type (61) = Virtual (5) 730 * Framed-Management-Protocol (TBA-2) = Web-based (2) 732 9. Secure web access, using a custom management access level, 733 defined by a policy: 735 * Service-Type (6) = Framed-Management (TBA-1) 736 * NAS-Port-Type (61) = Virtual (5) 737 * Framed-Management-Protocol (TBA-2) = Web-based (2) 738 * Management-Transport-Protection (TBA-3) = Integrity- 739 Confidentiality-Protection (3) 740 * Management-Policy-Id (TBA-4) = "Read-only web access" 742 9. Diameter Translation Considerations 744 When used in Diameter, the attributes defined in this specification 745 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 746 attribute compatibility space). No additional Diameter Code values 747 are therefore allocated. The data types and flag rules for the 748 attributes are as follows: 750 +---------------------+ 751 | AVP Flag rules | 752 |----+-----+----+-----|----+ 753 | | SHOULD MUST| | 754 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 755 ---------------------------------|----+-----+----+-----|----| 756 Service-Type (new value) | | | | | | 757 Enumerated | M | P | | V | Y | 758 Framed-Management-Protocol | | | | | | 759 Enumerated | M | P | | V | Y | 760 Management-Transport-Protection | | | | | | 761 Enumerated | M | P | | V | Y | 762 Management-Policy-Id | | | | | | 763 UTF8String | M | P | | V | Y | 764 Management-Privilege-Level | | | | | | 765 Integer | M | P | | V | Y | 766 ---------------------------------|----+-----+----+-----|----| 767 The attributes in this specification have no special translation 768 requirements for Diameter to RADIUS or RADIUS to Diameter gateways; 769 they are copied as is, except for changes relating to headers, 770 alignment, and padding. See also [RFC3588] Section 4.1 and [RFC4005] 771 Section 9. 773 What this specification says about the applicability of the 774 attributes for RADIUS Access-Request packets applies in Diameter to 775 AA-Request [RFC4005]. 777 What is said about Access-Accept applies in Diameter to AA-Answer 778 messages that indicate success. 780 10. Table of Attributes 782 The following table provides a guide to which attributes may be found 783 in which kinds of packets, and in what quantity. 785 Access Messages 786 Request Accept Reject Challenge # Attribute 787 --------------------------------------------------------------------- 788 0-1 0-1 0 0 TBA-2 Framed-Management-Protocol 789 0-1 0-1 0 0 TBA-3 Management-Transport-Protection 790 0 0-1 0 0 TBA-4 Management-Policy-Id 791 0 0-1 0 0 TBA-5 Management-Privilege-Level 793 Accounting Messages 794 Request Response # Attribute 795 --------------------------------------------------------------------- 796 0-1 0 TBA-2 Framed-Management-Protocol 797 0-1 0 TBA-3 Management-Transport-Protection 798 0-1 0 TBA-4 Management-Policy-Id 799 0-1 0 TBA-5 Management-Privilege-Level 801 Change-of-Authorization Messages 802 Request ACK NAK # Attribute 803 -------------------------------------------------------------------- 804 0 0 0 TBA-2 Framed-Management-Protocol 805 0 0 0 TBA-3 Management-Transport-Protection 806 0-1 0 0 TBA-4 Management-Policy-Id (Note 1) 807 0-1 0 0 TBA-5 Management-Privilege-Level (Note 1) 809 Disconnect Messages 810 Request ACK NAK # Attribute 811 ---------------------------------------------------------------------- 812 0 0 0 TBA-2 Framed-Management-Protocol 813 0 0 0 TBA-3 Management-Transport-Protection 814 0 0 0 TBA-4 Management-Policy-Id 815 0 0 0 TBA-5 Management-Privilege-Level 817 (Note 1) When included within a CoA-Request, these attributes 818 represent an authorization change request. When one of these 819 attributes is omitted from a CoA-Request, the NAS assumes that the 820 attribute value is to remain unchanged. Attributes included in a 821 CoA-Request replace all existing values of the same attribute(s). 823 The following table defines the meaning of the above table entries. 825 0 This attribute MUST NOT be present in a packet. 826 0+ Zero or more instances of this attribute MAY be present in 827 a packet. 828 0-1 Zero or one instance of this attribute MAY be present in 829 a packet. 830 1 Exactly one instance of this attribute MUST be present in 831 a packet. 833 11. IANA Considerations 835 This document contains placeholders ("TBA-n") for assigned numbers 836 within the RADIUS Attributes Types registry 837 (http://www.iana.org/assignments/radius-types), to be assigned by 838 IANA at the time this document should be published as an RFC. 839 o New enumerated value for the existing Service-Type Attribute: 840 * Framed-Management (TBA-1) 841 o New RADIUS Attribute Types: 842 * Framed-Management-Protocol (TBA-2) 843 * Management-Transport-Protection (TBA-3) 844 * Management-Policy-Id (TBA-4) 845 * Management-Privilege-Level (TBA-5) 847 The enumerated values of the newly assigned RADIUS Attribute Types as 848 defined in this document are to be assigned at the same time as the 849 new Attribute Types. 851 For the Framed-Management-Protocol Attribute: 853 1 SNMP 854 2 Web-based 855 3 NETCONF 856 4 FTP 857 5 TFTP 858 6 SFTP 859 7 RCP 860 8 SCP 862 For the Management-Transport-Protection Attribute: 864 1 No-Protection 865 2 Integrity-Protection 866 3 Integrity-Confidentiality-Protection 868 Assignments of additional enumerated values for the RADIUS attributes 869 defined in this document are to be processed as described in 870 [RFC3575], subject to the additional requirement of a published 871 specification. 873 12. Security Considerations 875 12.1. General Considerations 877 This specification describes the use of RADIUS and Diameter for 878 purposes of authentication, authorization and accounting for 879 management access to devices within networks. RADIUS threats and 880 security issues for this application are described in [RFC3579] and 881 [RFC3580]; security issues encountered in roaming are described in 882 [RFC2607]. For Diameter, the security issues relating to this 883 application are described in [RFC4005] and [RFC4072]. 885 This document specifies new attributes that can be included in 886 existing RADIUS packets, which may be protected as described in 887 [RFC3579] and [RFC5176]. In Diameter, the attributes are protected 888 as specified in [RFC3588]. See those documents for a more detailed 889 description. 891 The security mechanisms supported in RADIUS and Diameter are focused 892 on preventing an attacker from spoofing packets or modifying packets 893 in transit. They do not prevent an authorized RADIUS/Diameter server 894 or proxy from inserting attributes with malicious intent. 896 A legacy NAS may not recognize the attributes in this document that 897 supplement the provisioning of CLI management access. If the value 898 of the Service-Type Attribute is NAS-Prompt or Administrative, the 899 legacy NAS may silently discard such attributes, while permitting the 900 user to access the CLI management interface(s) of the NAS. This can 901 lead to users improperly receiving authorized management access to 902 the NAS, or access with greater levels of access rights than were 903 intended. RADIUS servers SHOULD attempt to ascertain whether or not 904 the NAS supports these attributes before sending them in an Access- 905 Accept provisioning CLI access. 907 It is possible that certain NAS implementations may not be able to 908 determine the protection properties of the underlying transport 909 protocol as specified by the Management-Transport-Protection 910 Attribute. This may be a limitation of the standard application 911 programming interface of the underlying transport implementation or 912 of the integration of the transport into the NAS implementation. In 913 either event, NASes conforming to this specification, which cannot 914 determine the protection state of the remote management connection 915 MUST treat an Access-Accept message containing a Management- 916 Transport-Protection Attribute containing a value other than No- 917 Protection (1) as if it were an Access-Reject message, unless 918 specifically overridden by local policy configuration. 920 Use of the No-Protection (1) option for the Management-Transport- 921 Protection (TBA-3) Attribute is NOT RECOMMENDED in any deployment 922 where secure management or configuration is required. 924 12.2. RADIUS Proxy Operation Considerations 926 The device management access authorization attributes presented in 927 this document present certain considerations when used in RADIUS 928 proxy environments. These considerations are not different from 929 those that exist in RFC 2865 [RFC2865] with respect to the Service- 930 Type Attribute values of Administrative and NAS-Prompt. 932 Most RADIUS proxy environments are also multi-party environments. In 933 multi-party proxy environments it is important to distinguish which 934 entities have the authority to provision management access to the 935 edge devices, i.e. NASes, and which entities only have authority to 936 provision network access services of various sorts. 938 It may be important that operators of the NAS are able to ensure that 939 access to the CLI, or other management interfaces of the NAS, is only 940 provisioned to their own employees or contractors. One way for the 941 NAS to enforce this requirement is to use only local, non-proxy 942 RADIUS servers for management access requests. Proxy RADIUS servers 943 could be used for non-management access requests, based on local 944 policy. This "bifurcation" of RADIUS authentication and 945 authorization is a simple case of separate administrative realms. 946 The NAS may be designed so as to maintain separate lists of RADIUS 947 servers for management AAA use and for non-management AAA use. 949 An alternate method of enforcing this requirement would be for the 950 first-hop RADIUS proxy server, operated by the owner of the NAS, to 951 filter out any RADIUS attributes that provision management access 952 rights that originate from "up-stream" proxy servers not operated by 953 the NAS owner. Access-Accept messages that provision such locally 954 un-authorized management access MAY be treated as if they were an 955 Access-Reject by the first-hop proxy server. 957 An additional exposure present in proxy deployments is that sensitive 958 user credentials, e.g passwords, are likely to be available in 959 cleartext form at each of the proxy servers. Encrypted or hashed 960 credentials are not subject to this risk, but password authentication 961 is a very commonly used mechanism for management access 962 authentication, and in RADIUS passwords are only protected on a hop- 963 by-hop basis. Malicious proxy servers could misuse this sensitive 964 information. 966 These issues are not of concern when all the RADIUS servers, local 967 and proxy, used by the NAS are under the sole administrative control 968 of the NAS owner. 970 13. Acknowledgments 972 Many thanks to all reviewers, including Bernard Aboba, Alan DeKok, 973 David Harrington, Mauricio Sanchez, Juergen Schoenwaelder, Hannes 974 Tschofenig, Barney Wolff and Glen Zorn. 976 14. References 978 14.1. Normative References 980 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 981 Requirement Levels", BCP 14, RFC 2119, March 1997. 983 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 984 "Remote Authentication Dial In User Service (RADIUS)", 985 RFC 2865, June 2000. 987 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 988 10646", STD 63, RFC 3629, November 2003. 990 14.2. Informative References 992 [HTML] Raggett, D., Le Hors, A., and I. Jacobs, "The HTML 4.01 993 Specification, W3C", December 1999. 995 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 996 STD 9, RFC 959, October 1985. 998 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, 999 RFC 1350, July 1992. 1001 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1002 Implementation in Roaming", RFC 2607, June 1999. 1004 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1005 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1006 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1008 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1010 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1011 Architecture for Describing Simple Network Management 1012 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1013 December 2002. 1015 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1016 "Message Processing and Dispatching for the Simple Network 1017 Management Protocol (SNMP)", STD 62, RFC 3412, 1018 December 2002. 1020 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 1021 Management Protocol (SNMP) Applications", STD 62, 1022 RFC 3413, December 2002. 1024 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1025 (USM) for version 3 of the Simple Network Management 1026 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1028 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 1029 Access Control Model (VACM) for the Simple Network 1030 Management Protocol (SNMP)", STD 62, RFC 3415, 1031 December 2002. 1033 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 1034 Simple Network Management Protocol (SNMP)", STD 62, 1035 RFC 3416, December 2002. 1037 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 1038 Management Protocol (SNMP)", STD 62, RFC 3417, 1039 December 2002. 1041 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1042 Simple Network Management Protocol (SNMP)", STD 62, 1043 RFC 3418, December 2002. 1045 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1046 Authentication Dial In User Service)", RFC 3575, 1047 July 2003. 1049 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1050 Dial In User Service) Support For Extensible 1051 Authentication Protocol (EAP)", RFC 3579, September 2003. 1053 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 1054 "IEEE 802.1X Remote Authentication Dial In User Service 1055 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1057 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1058 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1060 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1061 "Diameter Network Access Server Application", RFC 4005, 1062 August 2005. 1064 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1065 Authentication Protocol (EAP) Application", RFC 4072, 1066 August 2005. 1068 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1069 December 2006. 1071 [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF 1072 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 1073 December 2006. 1075 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access 1076 Protocol (SOAP)", RFC 4743, December 2006. 1078 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over 1079 the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, 1080 December 2006. 1082 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 1083 Aboba, "Dynamic Authorization Extensions to Remote 1084 Authentication Dial In User Service (RADIUS)", RFC 5176, 1085 January 2008. 1087 [SFTP] Galbraith, J. and O. Saarenmaa, "SSH File Transfer 1088 Protocol", July 2006. 1090 [SSH] Barrett, D., Silverman, R., and R. Byrnes, "SSH, the 1091 Secure Shell: The Definitive Guide, Second Edition, 1092 O'Reilly and Associates", May 2005. 1094 Authors' Addresses 1096 David B. Nelson 1097 Elbrys Networks, Inc. 1098 75 Rochester Avenue, Unit 3 1099 Portsmouth, NH 03801 1100 USA 1102 Email: d.b.nelson@comcast.net 1104 Greg Weber 1105 Individual Contributor 1106 Knoxville, TN 37932 1107 USA 1109 Email: gdweber@gmail.com