idnits 2.17.1 draft-ietf-radext-management-authorization-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1027. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1038. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1045. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1051. 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 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5755 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 (==), 12 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: January 15, 2009 Individual Contributor 6 July 14, 2008 8 Remote Authentication Dial-In User Service (RADIUS) Authorization for 9 Network Access Server (NAS) Management 10 draft-ietf-radext-management-authorization-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 15, 2009. 37 Abstract 39 This document specifies Remote Authentication Dial-In User Service 40 (RADIUS) attributes for authorizing management access to a Network 41 Access Server (NAS). Both local and remote management are supported, 42 with granular access rights and management privileges. Specific 43 provisions are made for remote management via framed management 44 protocols, and for management access over a secure transport 45 protocol. 47 Table of Contents 49 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4. New Values for Existing RADIUS Attributes . . . . . . . . . . 5 53 4.1. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. New RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 5 55 5.1. Framed-Management-Protocol . . . . . . . . . . . . . . . . 5 56 5.2. Management-Transport-Protection . . . . . . . . . . . . . 7 57 5.3. Management-Policy-Id . . . . . . . . . . . . . . . . . . . 10 58 5.4. Management-Privilege-Level . . . . . . . . . . . . . . . . 11 59 6. Use with Dynamic Authorization . . . . . . . . . . . . . . . . 12 60 7. Examples of attribute groupings . . . . . . . . . . . . . . . 13 61 8. Diameter Translation Considerations . . . . . . . . . . . . . 15 62 9. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 16 63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 64 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 65 11.1. General Considerations . . . . . . . . . . . . . . . . . . 18 66 11.2. RADIUS Proxy Operation Considerations . . . . . . . . . . 19 67 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 68 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 69 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 70 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 72 Intellectual Property and Copyright Statements . . . . . . . . . . 24 74 1. Terminology 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 80 This document uses terminology from RFC 2865 [RFC2865], RFC 2866 81 [RFC2866] and RFC 5176 [RFC5176]. 83 2. Introduction 85 RFC 2865 [RFC2865] defines the NAS-Prompt (7) and Administrative (6) 86 values of the Service-Type (6) Attribute. Both of these values 87 provide access to the interactive, text-based Command Line Interface 88 (CLI) of the NAS, and were originally developed to control access to 89 the physical console port of the NAS, most often a serial port. 91 Remote access to the CLI of the NAS has been available in NAS 92 implementations for many years, using protocols such as Telnet, 93 Rlogin and the remote terminal service of the Secure SHell (SSH). In 94 order to distinguish local, physical, console access from remote 95 access, the NAS-Port-Type (61) Attribute is generally included in 96 Access-Request and Access-Accept messages, along with the Service- 97 Type (6) Attribute, to indicate the form of access. A NAS-Port-Type 98 (61) Attribute with a value of of Async (0) is used to signify a 99 local serial port connection, while a value of Virtual (5) is used to 100 signify a remote connection, via a remote terminal protocol. This 101 usage provides no selectivity among the various available remote 102 terminal protocols (e.g. Telnet, Rlogin, SSH, etc.). 104 Today, it is common for network devices to support more than the two 105 privilege levels for management access provided by the Service-Type 106 (6) Attribute with values of NAS-Prompt (7) (non-privileged) and 107 Administrative (6) (privileged). Also, other management mechanisms 108 may be used, such as Web-based management, Simple Network Management 109 Protocol (SNMP) and NETCONF. To provide support for these additional 110 features, this specification defines attributes for Framed Management 111 protocols, management protocol security, and management access 112 privilege levels. 114 Remote management via the command line is carried over protocols such 115 as Telnet, Rlogin and the remote terminal service of SSH. Since 116 these protocols are primarily for the delivery of terminal or pseudo- 117 TTY services, the term "Framed Management" is used to describe 118 management protocols supporting techniques other than the command- 119 line. Typically these mechanisms format management information in a 120 binary or textual encoding such as HTML, XML or ASN.1/BER. Examples 121 include Web-based management (HTML over HTTP or HTTPS), NETCONF (XML 122 over SSH/BEEP/SOAP) and SNMP (SMI over ASN.1/BER). Command line 123 interface, menu interface or other text-based (e.g. ASCII or UTF-8) 124 terminal emulation services are not considered to be Framed 125 Management protocols. 127 3. Overview 129 To support the authorization and provisioning of Framed Management 130 access to managed entities, this document introduces a new value for 131 the Service-Type (6) Attribute [RFC2865], and one new attribute. The 132 new value for the Service-Type (6) Attribute is Framed-Management 133 (TBA-1), used for remote device management via a Framed Management 134 protocol. The new attribute is Framed-Management-Protocol (TBA-2), 135 the value of which specifies a particular protocol for use in the 136 remote management session. 138 Two new attributes are introduced in this document in support of 139 granular management access rights or command privilege levels. The 140 Management-Policy-Id (TBA-4) Attribute provides a text string 141 specifying a policy name of local scope, that is assumed to have been 142 pre-provisioned on the NAS. This use of an attribute to specify use 143 of a pre-provisioned policy is similar to the Filter-Id (11) 144 Attribute defined in [RFC2865] Section 5.11. 146 The local application of the Management-Policy-Id (TBA-4) Attribute 147 within the managed entity may take the form of (a) one of an 148 enumeration of command privilege levels, (b) a mapping into an SNMP 149 Access Control Model, such as the View Based Access Control Model 150 (VACM) [RFC3415], or (c) some other set of management access policy 151 rules that is mutually understood by the managed entity and the 152 remote management application. Examples are given in Section 7. 154 The Management-Privilege-Level (TBA-5) Attribute contains an integer- 155 valued management privilege level indication. This attribute serves 156 to modify or augment the management permissions provided by the NAS- 157 Prompt (7) value of the Service-Type (6) Attribute, and thus applies 158 to CLI management. 160 To enable management security requirements to be specified, the 161 Management-Transport-Protection (TBA-3) Attribute is introduced. The 162 value of this attribute indicates the minimum level of secure 163 transport protocol protection required for the provisioning of NAS- 164 Prompt (7), Administrative (6) or Framed-Management (TBA-1) service. 166 4. New Values for Existing RADIUS Attributes 168 4.1. Service-Type 170 The Service-Type (6) Attribute is defined in Section 5.6 of RFC 2865 171 [RFC2865]. This document defines a new value of the Service-Type 172 Attribute, as follows: 174 (TBA-1) Framed-Management 176 The semantics of the Framed-Management service are as follows: 178 Framed-Management A framed management protocol session should 179 be started on the NAS. 181 5. New RADIUS Attributes 183 This document defines four new RADIUS attributes related to 184 management authorization. 186 5.1. Framed-Management-Protocol 188 The Framed-Management-Protocol (TBA-2) Attribute indicates the 189 application-layer management protocol to be used for Framed 190 Management access. It MAY be used in both Access-Request and Access- 191 Accept packets. This attribute is used in conjunction with a 192 Service-Type (6) Attribute with the value of Framed-Management 193 (TBA-1). 195 It is RECOMMENDED that the NAS include an appropriately valued 196 Framed-Management-Protocol (TBA-2) Attribute in an Access-Request 197 packet, indicating the type of management access being requested. It 198 is further RECOMMENDED that the NAS include a Service-Type (6) 199 Attribute with the value Framed-Management (TBA-1) in the same 200 Access-Request packet. The RADIUS server MAY use these attributes as 201 a hint in making its authorization decision. 203 The RADIUS server MAY include a Framed-Management-Protocol (TBA-2) 204 Attribute in an Access-Accept packet that also includes a Service- 205 Type (6) Attribute with a value of Framed-Management (TBA-1), when 206 the RADIUS Server chooses to enforce a management access policy for 207 the authenticated user that dictates one form of management access in 208 preference to others. 210 When a NAS receives a Framed-Management-Protocol (TBA-2) Attribute in 211 an Access-Accept packet, it MUST deliver that specified form of 212 management access or disconnect the session. If the NAS does not 213 support the provisioned management application-layer protocol, or the 214 management access protocol requested by the user does not match that 215 of the Framed-Management-Protocol (TBA-2) Attribute in the Access- 216 Accept packet, the NAS MUST treat the Access-Accept packet as if it 217 had been an Access-Reject. 219 A summary of the Framed-Management-Protocol (TBA-2) Attribute format 220 is shown below. The fields are transmitted from left to right. 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Type | Length | Value 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Value (cont) | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Type 232 (TBA-2) for Framed-Management-Protocol. 234 Length 236 6 238 Value 240 The Value field is a four octet enumerated value. 242 1 SNMP 243 2 Web-based 244 3 NETCONF 245 4 FTP 246 5 TFTP 247 6 SFTP 248 7 RCP 249 8 SCP 251 All other values are reserved for IANA allocation subject to the 252 provisions of Section 10. 254 The acronyms used in the above table expand as follows: 256 o SNMP: Simple Network Management Protocol. [RFC3411], [RFC3412], 257 [RFC3413], [RFC3414], [RFC3415], [RFC3416], [RFC3417], [RFC3418] 259 o Web-based: Use of an embedded web server in the NAS for management 260 via a generic web browser client. The interface presented to the 261 administrator may be graphical, tabular or textual. The protocol 262 is HTML over HTTP. The protocol may optionally be HTML over 263 HTTPS, i.e. using HTTP over TLS. [HTML] [RFC2616] 265 o NETCONF: Management via the NETCONF protocol using XML over 266 supported transports (e.g. SSH, BEEP, SOAP). As secure transport 267 profiles are defined for NETCONF, the list of transport options 268 may expand. [RFC4741], [RFC4742], [RFC4743], [RFC4744] 270 o FTP: File Transfer Protocol, used to transfer configuration files 271 to and from the NAS. [RFC0959] 273 o TFTP: Trivial File Transfer Protocol, used to transfer 274 configuration files to and from the NAS. [RFC1350] 276 o SFTP: SSH File Transfer Protocol, used to securely transfer 277 configuration files to and from the NAS. SFTP uses the services 278 of SSH. [SFTP] See also Section 3.7, "SSH and File Transfers" of 279 [SSH]. Additional information on the "sftp" program may typically 280 be found in the online documentation ("man" pages) of Unix 281 systems. 283 o RCP: Remote CoPy file copy utility (Unix-based), used to transfer 284 configuration files to and from the NAS. See Section 3.7, "SSH 285 and File Transfers" of [SSH]. Additional information on the "rcp" 286 program may typically be found in the online documentation ("man" 287 pages) of Unix systems. 289 o SCP: Secure CoPy file copy utility (Unix-based), used to transfer 290 configuration files to and from the NAS. The "scp" program is a 291 simple wrapper around SSH. It's basically a patched BSD Unix 292 "rcp" which uses ssh to do the data transfer (instead of using 293 "rcmd"). See Section 3.7, "SSH and File Transfers" of [SSH]. 294 Additional information on the "scp" program may typically be found 295 in the online documentation ("man" pages) of Unix systems. 297 5.2. Management-Transport-Protection 299 The Management-Transport-Protection (TBA-3) Attribute specifies the 300 minimum level of protection that is required for a protected 301 transport used with the framed or non-framed management access 302 session. The protected transport used by the NAS MAY provide a 303 greater level of protection, but MUST NOT provide a lower level of 304 protection. 306 When a secure form of non-framed management access is specified, it 307 means that the remote terminal session is encapsulated in some form 308 of protected transport, or tunnel. It may also mean that an explicit 309 secure mode of operation is required, when the framed management 310 protocol contains an intrinsic secure mode of operation. The 311 Management-Transport-Protection (TBA-3) Attribute does not apply to 312 CLI access via a local serial port, or other non-remote connection. 314 When a secure form of Framed Management access is specified, it means 315 that the application-layer management protocol is encapsulated in 316 some form of protected transport, or tunnel. It may also mean that 317 an explicit secure mode of operation is required, when the Framed 318 Management protocol contains an intrinsic secure mode of operation. 320 A value of "No Protection (1)" indicates that a secure transport 321 protocol is not required, and that the NAS SHOULD accept a connection 322 over any transport associated with the application-layer management 323 protocol. The definitions of management application to transport 324 bindings are defined in the relevant documents that specify those 325 management application protocols. The same "No Protection" semantics 326 are conveyed by omitting this attribute from an Access-Accept packet. 328 Specific protected transport protocols, cipher suites, key agreement 329 methods, or authentication methods are not specified by this 330 attribute. Such provisioning is beyond the scope of this document. 332 It is RECOMMENDED that the NAS include an appropriately valued 333 Management-Transport-Protection (TBA-3) Attribute in an Access- 334 Request packet, indicating the level of transport protection for the 335 management access being requested, when that information is available 336 to the RADIUS client. The RADIUS server MAY use this attribute as a 337 hint in making its authorization decision. 339 The RADIUS server MAY include a Management-Transport-Protection 340 (TBA-3) Attribute in an Access-Accept packet that also includes a 341 Service-Type (6) Attribute with a value of Framed-Management (TBA-1), 342 when the RADIUS Server chooses to enforce an management access 343 security policy for the authenticated user that dictates a minimum 344 level of transport security. 346 When a NAS receives a Management-Transport-Protection (TBA-3) 347 Attribute in an Access-Accept packet, it MUST deliver the management 348 access over a transport with equal or better protection 349 characteristics or disconnect the session. If the NAS does not 350 support protected management transport protocols, or the level of 351 protection available does not match that of the Management-Transport- 352 Protection (TBA-3) Attribute in the Access-Accept packet, the NAS 353 MUST treat the response packet as if it had been an Access-Reject. 355 A summary of the Management-Transport-Protection (TBA-3) Attribute 356 format is shown below. The fields are transmitted from left to 357 right. 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type | Length | Value 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Value (cont) | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Type 369 (TBA-3) for Management-Transport-Protection. 371 Length 373 6 375 Value 377 The Value field is a four octet enumerated value. 379 1 No-Protection 380 2 Integrity-Protection 381 3 Integrity-Confidentiality-Protection 383 All other values are reserved for IANA allocation subject to the 384 provisions of Section 10. 386 The names used in the above table are elaborated as follows: 388 o No-Protection: No transport protection is required. Accept 389 connections via any supported transport. 391 o Integrity-Protection: The management transport MUST provide 392 Integrity Protection, i.e. protection from unauthorized 393 modification, using a cryptographic checksum. 395 o Integrity-Confidentiality-Protection: The management transport 396 MUST provide both Integrity Protection and Confidentiality 397 Protection, i.e. protection from unauthorized modification, using 398 a cryptographic checksum, and protection from unauthorized 399 disclosure, using encryption. 401 The configuration or negotiation of acceptable algorithms, modes and 402 credentials for the cryptographic protection mechanisms used in 403 implementing protected management transports is outside the scope of 404 this document. Many such mechanisms have standardized methods of 405 configuration and key management. 407 5.3. Management-Policy-Id 409 The Management-Policy-Id (TBA-4) Attribute indicates the name of the 410 management access policy for this user. Zero or one Management- 411 Policy-Id (TBA-4) Attributes MAY be sent in an Access-Accept packet. 412 Identifying a policy by name allows the policy to be used on 413 different NASes without regard to implementation details. 415 Multiple forms of management access rules may be expressed by the 416 underlying named policy, the definition of which is beyond the scope 417 of this document. The management access policy MAY be applied 418 contextually, based on the nature of the management access method. 419 For example, some named policies may only be valid for application to 420 NAS-Prompt (7) services and some other policies may only be valid for 421 SNMP. 423 The management access policy named in this attribute, received in an 424 Access-Accept packet, MUST be applied to the session authorized by 425 the Access-Accept. If the NAS supports this attribute, but the 426 policy name is unknown, or if the RADIUS client is able to determine 427 that the policy rules are incorrectly formatted, the NAS MUST treat 428 the Access-Accept packet as if it had been an Access-Reject. 430 No precedence relationship is defined for multiple occurrences of the 431 Management-Policy-Id (TBA-4) Attribute. NAS behavior in such cases 432 is undefined. Therefore, two or more occurrences of this attribute 433 SHOULD NOT be included in an Access-Accept or CoA-Request. 435 The content of the Management-Policy-Id (TBA-4) Attribute is expected 436 to be the name of a management access policy of local significance to 437 the NAS, within a namespace of significance to the NAS. In this 438 regard, the behavior is similar to that for the Filter-Id (11) 439 Attribute. The policy names and rules are committed to the local 440 configuration data-store of the NAS, and are provisioned by means 441 beyond the scope of this document, such as via SNMP, NETCONF or CLI. 443 The namespace used in the Management-Policy-Id (TBA-4) Attribute is 444 simple and monolithic. There is no explicit or implicit structure or 445 hierarchy . For example, in the text string "example.com", the "." 446 (period or dot) is just another character. It is expected that text 447 string matching will be performed without parsing the text string 448 into any sub-fields. 450 Overloading or subdividing this simple name with multi-part 451 specifiers (e.g. Access=remote, Level=7) is likely to lead to poor 452 multi-vendor interoperability and SHOULD NOT be utilized. If a 453 simple, unstructured policy name is not sufficient, it is RECOMMENDED 454 that a Vendor Specific (26) Attribute be used instead, rather than 455 overloading the semantics of Management-Policy-Id. 457 A summary of the Management-Policy-Id (TBA-4) Attribute format is 458 shown below. The fields are transmitted from left to right. 460 0 1 2 461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 463 | Type | Length | Text ... 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 466 Type 468 (TBA-4) for Management-Policy-Id. 470 Length 472 >= 3 474 Text 476 The Text field is one or more octets, and its contents are 477 implementation dependent. It is intended to be human readable and 478 MUST NOT affect operation of the protocol. It is recommended that 479 the message contain UTF-8 encoded 10646 [RFC3629] characters. 481 5.4. Management-Privilege-Level 483 The Management-Privilege-Level (TBA-5) Attribute indicates the 484 integer-valued privilege level to be assigned for management access 485 for the authenticated user. Many NASes provide the notion of 486 differentiated management privilege levels denoted by an integer 487 value. The specific access rights conferred by each value are 488 implementation dependent. It MAY be used in both Access-Request and 489 Access-Accept packets. 491 The management access level indicated in this attribute, received in 492 an Access-Accept packet, MUST be applied to the session authorized by 493 the Access-Accept. If the NAS supports this attribute, but the 494 privilege level is unknown, the NAS MUST treat the Access-Accept 495 packet as if it had been an Access-Reject. 497 A summary of the Management-Privilege-Level (TBA-5) Attribute format 498 is show below. The fields are transmitted from left to right. 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Type | Length | Value 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Value (cont) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Type 510 (TBA-5) for Management-Privilege-Level. 512 Length 514 6 516 Value 518 The Value field is a four octet Integer, denoting a management 519 privilege level. 521 It is RECOMMENDED to limit use of the Management-Privilege-Level 522 (TBA-5) Attribute to sessions where the Service-Type (6) Attribute 523 has a value of NAS-Prompt (7) (not Administrative). Typically, NASes 524 treat NAS-Prompt as the minimal privilege CLI service and 525 Administrative as full privilege. Using the Management-Privilege- 526 Level (TBA-5) Attribute with a Service-Type (6) Attribute having a 527 value of NAS-Prompt (7) will have the effect of increasing the 528 minimum privilege level. Conversely, it is NOT RECOMMENDED to use 529 this attribute with a Service-Type (6) Attribute with a value of of 530 Administrative (6), which may require decreasing the maximum 531 privilege level. 533 It is NOT RECOMMENDED to use the Management-Privilege-Level (TBA-5) 534 Attribute in combination with a Management-Policy-Id (TBA-4) 535 Attribute or for management access methods other than interactive 536 CLI. The behavior resulting from such an overlay of management 537 access control provisioning is not defined by this document, and in 538 the absence of further specification is likely to lead to unexpected 539 behaviors, especially in multi-vendor environments. 541 6. Use with Dynamic Authorization 543 It is entirely OPTIONAL for the NAS management authorization 544 attributes specified in this document to be used in conjunction with 545 Dynamic Authorization extensions to RADIUS [RFC5176]. When such 546 usage occurs, those attributes MAY be used as listed in the Table of 547 Attributes in Section 9. 549 Some guidance on how to identify existing management sessions on a 550 NAS for the purposes of Dynamic Authorization is useful. The primary 551 session identifiers SHOULD be User-Name (1) and Service-Type (6). To 552 accommodate instances when that information alone does not uniquely 553 identify a session, a NAS supporting Dynamic Authorization SHOULD 554 maintain one or more internal session identifiers that can be 555 represented as RADIUS Attributes. Examples of such attributes 556 include Acct-Session-Id (44), Acct-Multi-Session-Id (50), NAS-Port 557 (5) or NAS-Port-Id (87). In the case of a remote management session, 558 common identifier values might include things such as the remote IP 559 address and remote TCP port number, or the file descriptor value for 560 use with the open socket. Any such identifier is obviously transient 561 in nature, and implementations SHOULD take care to avoid and/or 562 properly handle duplicate or stale values. 564 In order for the session identification attributes to be available to 565 the Dynamic Authorization Client, a NAS supporting Dynamic 566 Authorization for management sessions SHOULD include those session 567 identification attributes in the Access-Request message for each such 568 session. Additional discussion of session identification attribute 569 usage may be found in Section 3 of [RFC5176]. 571 7. Examples of attribute groupings 573 1. Unprotected CLI access, via the local console, to the "super- 574 user" access level: 576 * Service-Type (6) = Administrative (6) 577 * NAS-Port-Type (61) = Async (0) 578 * Management-Transport-Protection (TBA-3) = No-Protection (1) 580 2. Unprotected CLI access, via a remote console, to the "super-user" 581 access level: 583 * Service-Type (6) = Administrative (6) 584 * NAS-Port-Type (61) = Virtual (5) 585 * Management-Transport-Protection (TBA-3) = No-Protection (1) 587 3. CLI access, via a fully-protected secure remote terminal service 588 to the non-privileged user access level: 590 * Service-Type (6) = NAS-Prompt (7) 591 * NAS-Port-Type (61) = Virtual (5) 592 * Management-Transport-Protection (TBA-3) = Integrity- 593 Confidentiality-Protection (3) 595 4. CLI access, via a fully-protected secure remote terminal service, 596 to a custom management access level, defined by a policy: 598 * Service-Type (6) = NAS-Prompt (7) 599 * NAS-Port-Type (61) = Virtual (5) 600 * Management-Transport-Protection (TBA-3) = Integrity- 601 Confidentiality-Protection (3) 602 * Management-Policy-Id (TBA-4) = "Network Administrator" 604 5. CLI access, via a fully-protected secure remote terminal service, 605 with a management privilege level of 15: 607 * Service-Type (6) = NAS-Prompt (7) 608 * NAS-Port-Type (61) = Virtual (5) 609 * Management-Transport-Protection (TBA-3) = Integrity- 610 Confidentiality-Protection (3) 611 * Management-Privilege-Level (TBA-5) = 15 613 6. SNMP access, using an Access Control Model specifier, such as a 614 custom VACM View, defined by a policy: 616 * Service-Type (6) = Framed-Management (TBA-1) 617 * NAS-Port-Type (61) = Virtual (5) 618 * Framed-Management-Protocol (TBA-2) = SNMP (1) 619 * Management-Policy-Id (TBA-4) = "SNMP Network Administrator 620 View" 622 There is currently no standardized way of implementing this 623 management policy mapping within SNMP. Such mechanisms are the 624 topic of current research. 626 7. SNMP fully-protected access: 628 * Service-Type (6) = Framed-Management (TBA-1) 629 * NAS-Port-Type (61) = Virtual (5) 630 * Framed-Management-Protocol (TBA-2) = SNMP (1) 631 * Management-Transport-Protection (TBA-3) = Integrity- 632 Confidentiality-Protection (3) 634 8. Web (HTTP/HTML) access: 636 * Service-Type (6) = Framed-Management (TBA-1) 637 * NAS-Port-Type (61) = Virtual (5) 638 * Framed-Management-Protocol (TBA-2) = Web-based (2) 640 9. Secure web access, using a custom management access level, 641 defined by a policy: 643 * Service-Type (6) = Framed-Management (TBA-1) 644 * NAS-Port-Type (61) = Virtual (5) 645 * Framed-Management-Protocol (TBA-2) = Web-based (2) 646 * Management-Transport-Protection (TBA-3) = Integrity- 647 Confidentiality-Protection (3) 648 * Management-Policy-Id (TBA-4) = "Read-only web access" 650 8. Diameter Translation Considerations 652 When used in Diameter, the attributes defined in this specification 653 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 654 attribute compatibility space). No additional Diameter Code values 655 are therefore allocated. The data types and flag rules for the 656 attributes are as follows: 658 +---------------------+ 659 | AVP Flag rules | 660 |----+-----+----+-----|----+ 661 | | |SHLD| MUST| | 662 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 663 ---------------------------------|----+-----+----+-----|----| 664 Service-Type (new value) | | | | | | 665 Enumerated | M | P | | V | Y | 666 Framed-Management-Protocol | | | | | | 667 Enumerated | M | P | | V | Y | 668 Management-Transport-Protection | | | | | | 669 Enumerated | M | P | | V | Y | 670 Management-Policy-Id | | | | | | 671 UTF8String | M | P | | V | Y | 672 Management-Privilege-Level | | | | | | 673 Integer | M | P | | V | Y | 674 ---------------------------------|----+-----+----+-----|----| 676 The attributes in this specification have no special translation 677 requirements for Diameter to RADIUS or RADIUS to Diameter gateways; 678 they are copied as is, except for changes relating to headers, 679 alignment, and padding. See also [RFC3588] Section 4.1 and [RFC4005] 680 Section 9. 682 What this specification says about the applicability of the 683 attributes for RADIUS Access-Request packets applies in Diameter to 684 AA-Request [RFC4005]. 686 What is said about Access-Accept applies in Diameter to AA-Answer 687 messages that indicate success. 689 9. Table of Attributes 691 The following table provides a guide to which attributes may be found 692 in which kinds of packets, and in what quantity. 694 Access Messages 695 Request Accept Reject Challenge # Attribute 696 --------------------------------------------------------------------- 697 0-1 0-1 0 0 TBA-2 Framed-Management-Protocol 698 0-1 0-1 0 0 TBA-3 Management-Transport-Protection 699 0 0-1 0 0 TBA-4 Management-Policy-Id 700 0 0-1 0 0 TBA-5 Management-Privilege-Level 702 Accounting Messages 703 Request Response # Attribute 704 --------------------------------------------------------------------- 705 0-1 0 TBA-2 Framed-Management-Protocol 706 0-1 0 TBA-3 Management-Transport-Protection 707 0-1 0 TBA-4 Management-Policy-Id 708 0-1 0 TBA-5 Management-Privilege-Level 710 Change-of-Authorization Messages 711 Request ACK NAK # Attribute 712 -------------------------------------------------------------------- 713 0 0 0 TBA-2 Framed-Management-Protocol 714 0 0 0 TBA-3 Management-Transport-Protection 715 0-1 0 0 TBA-4 Management-Policy-Id (Note 1) 716 0-1 0 0 TBA-5 Management-Privilege-Level (Note 1) 718 Disconnect Messages 719 Request ACK NAK # Attribute 720 ---------------------------------------------------------------------- 721 0 0 0 TBA-2 Framed-Management-Protocol 722 0 0 0 TBA-3 Management-Transport-Protection 723 0 0 0 TBA-4 Management-Policy-Id 724 0 0 0 TBA-5 Management-Privilege-Level 726 (Note 1) When included within a CoA-Request, these attributes 727 represent an authorization change request. When one of these 728 attributes is omitted from a CoA-Request, the NAS assumes that the 729 attribute value is to remain unchanged. Attributes included in a 730 CoA-Request replace all existing values of the same attribute(s). 732 The following table defines the meaning of the above table entries. 734 0 This attribute MUST NOT be present in a packet. 735 0+ Zero or more instances of this attribute MAY be present in 736 a packet. 737 0-1 Zero or one instance of this attribute MAY be present in 738 a packet. 739 1 Exactly one instance of this attribute MUST be present in 740 a packet. 742 10. IANA Considerations 744 Note to RFC Editor: Remove the following paragraphs upon publication 745 of this document as an RFC. 747 This document contains placeholders ("TBA-n") for assigned numbers 748 within the RADIUS Attributes Types registry 749 (http://www.iana.org/assignments/radius-types), to be assigned by 750 IANA at the time this document should be published as an RFC. 751 o New enumerated value for the existing Service-Type Attribute: 752 * Framed-Management (TBA-1) 753 o New RADIUS Attribute Types: 754 * Framed-Management-Protocol (TBA-2) 755 * Management-Transport-Protection (TBA-3) 756 * Management-Policy-Id (TBA-4) 757 * Management-Privilege-Level (TBA-5) 759 The enumerated values of the newly assigned RADIUS Attribute Types as 760 defined in this document are to be assigned at the same time as the 761 new Attribute Types. 763 For the Framed-Management-Protocol Attribute: 765 1 SNMP 766 2 Web-based 767 3 NETCONF 768 4 FTP 769 5 TFTP 770 6 SFTP 771 7 RCP 772 8 SCP 774 For the Management-Transport-Protection Attribute: 776 1 No-Protection 777 2 Integrity-Protection 778 3 Integrity-Confidentiality-Protection 780 Note to RFC Editor: Retain the following paragraph upon publication 781 of this document as an RFC. 783 Assignments of additional enumerated values for the RADIUS attributes 784 defined in this document are to be processed as described in 785 [RFC3575], subject to the additional requirement of a published 786 specification. 788 11. Security Considerations 790 11.1. General Considerations 792 This specification describes the use of RADIUS and Diameter for 793 purposes of authentication, authorization and accounting for 794 management access to devices within networks. RADIUS threats and 795 security issues for this application are described in [RFC3579] and 796 [RFC3580]; security issues encountered in roaming are described in 797 [RFC2607]. For Diameter, the security issues relating to this 798 application are described in [RFC4005] and [RFC4072]. 800 This document specifies new attributes that can be included in 801 existing RADIUS packets, which may be protected as described in 802 [RFC3579] and [RFC5176]. In Diameter, the attributes are protected 803 as specified in [RFC3588]. See those documents for a more detailed 804 description. 806 The security mechanisms supported in RADIUS and Diameter are focused 807 on preventing an attacker from spoofing packets or modifying packets 808 in transit. They do not prevent an authorized RADIUS/Diameter server 809 or proxy from inserting attributes with malicious intent. 811 A legacy NAS may not recognize the attributes in this document that 812 supplement the provisioning of CLI management access. If the value 813 of the Service-Type Attribute is NAS-Prompt or Administrative, the 814 legacy NAS may silently discard such attributes, while permitting the 815 user to access the CLI management interface(s) of the NAS. This can 816 lead to users improperly receiving authorized management access to 817 the NAS, or access with greater levels of access rights than were 818 intended. RADIUS servers SHOULD attempt to ascertain whether or not 819 the NAS supports these attributes before sending them in an Access- 820 Accept provisioning CLI access. 822 It is possible that certain NAS implementations may not be able to 823 determine the protection properties of the underlying transport 824 protocol as specified by the Management-Transport-Protection 825 Attribute. This may be a limitation of the standard application 826 programming interface of the underlying transport implementation or 827 of the integration of the transport into the NAS implementation. In 828 either event, NASes conforming to this specification, which cannot 829 determine the protection state of the remote management connection 830 MUST treat an Access-Accept message containing a Management- 831 Transport-Protection Attribute containing a value other than No- 832 Protection (1) as if it were an Access-Reject message, unless 833 specifically overridden by local policy configuration. 835 11.2. RADIUS Proxy Operation Considerations 837 The device management access authorization attributes presented in 838 this document present certain considerations when used in RADIUS 839 proxy environments. These considerations are not different from 840 those that exist in RFC 2865 [RFC2865] with respect to the Service- 841 Type Attribute values of Administrative and NAS-Prompt. 843 Most RADIUS proxy environments are also multi-party environments. In 844 multi-party proxy environments it is important to distinguish which 845 entities have the authority to provision management access to the 846 edge devices, i.e. NASes, and which entities only have authority to 847 provision network access services of various sorts. 849 It may be important that operators of the NAS are able to ensure that 850 access to the CLI, or other management interfaces of the NAS, is only 851 provisioned to their own employees or contractors. One way for the 852 NAS to enforce this requirement is to use only local, non-proxy 853 RADIUS servers for management access requests. Proxy RADIUS servers 854 could be used for non-management access requests, based on local 855 policy. This "bifurcation" of RADIUS authentication and 856 authorization is a simple case of separate administrative realms. 857 The NAS may be designed so as to maintain separate lists of RADIUS 858 servers for management AAA use and for non-management AAA use. 860 An alternate method of enforcing this requirement would be for the 861 first-hop RADIUS proxy server, operated by the owner of the NAS, to 862 filter out any RADIUS attributes that provision management access 863 rights that originate from "up-stream" proxy servers not operated by 864 the NAS owner. Access-Accept messages that provision such locally 865 un-authorized management access MAY be treated as if they were an 866 Access-Reject by the first-hop proxy server. 868 These issues are not of concern when all the RADIUS servers, local 869 and proxy, used by the NAS are under the sole administrative control 870 of the NAS owner. 872 12. Acknowledgments 874 Many thanks to all reviewers, including Bernard Aboba, Alan DeKok, 875 David Harrington, Mauricio Sanchez, Juergen Schoenwaelder, Barney 876 Wolff and Glen Zorn. 878 13. References 880 13.1. Normative References 882 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 883 Requirement Levels", BCP 14, RFC 2119, March 1997. 885 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 886 "Remote Authentication Dial In User Service (RADIUS)", 887 RFC 2865, June 2000. 889 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 890 10646", STD 63, RFC 3629, November 2003. 892 13.2. Informative References 894 [HTML] Raggett, D., Le Hors, A., and I. Jacobs, "The HTML 4.01 895 Specification, W3C", December 1999. 897 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 898 STD 9, RFC 959, October 1985. 900 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, 901 RFC 1350, July 1992. 903 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 904 Implementation in Roaming", RFC 2607, June 1999. 906 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 907 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 908 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 910 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 912 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 913 Architecture for Describing Simple Network Management 914 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 915 December 2002. 917 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 918 "Message Processing and Dispatching for the Simple Network 919 Management Protocol (SNMP)", STD 62, RFC 3412, 920 December 2002. 922 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 923 Management Protocol (SNMP) Applications", STD 62, 924 RFC 3413, December 2002. 926 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 927 (USM) for version 3 of the Simple Network Management 928 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 930 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 931 Access Control Model (VACM) for the Simple Network 932 Management Protocol (SNMP)", STD 62, RFC 3415, 933 December 2002. 935 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 936 Simple Network Management Protocol (SNMP)", STD 62, 937 RFC 3416, December 2002. 939 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 940 Management Protocol (SNMP)", STD 62, RFC 3417, 941 December 2002. 943 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 944 Simple Network Management Protocol (SNMP)", STD 62, 945 RFC 3418, December 2002. 947 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 948 Authentication Dial In User Service)", RFC 3575, 949 July 2003. 951 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 952 Dial In User Service) Support For Extensible 953 Authentication Protocol (EAP)", RFC 3579, September 2003. 955 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 956 "IEEE 802.1X Remote Authentication Dial In User Service 957 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 959 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 960 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 962 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 963 "Diameter Network Access Server Application", RFC 4005, 964 August 2005. 966 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 967 Authentication Protocol (EAP) Application", RFC 4072, 968 August 2005. 970 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 971 December 2006. 973 [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF 974 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 975 December 2006. 977 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access 978 Protocol (SOAP)", RFC 4743, December 2006. 980 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over 981 the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, 982 December 2006. 984 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 985 Aboba, "Dynamic Authorization Extensions to Remote 986 Authentication Dial In User Service (RADIUS)", RFC 5176, 987 January 2008. 989 [SFTP] Galbraith, J. and O. Saarenmaa, "SSH File Transfer 990 Protocol", July 2006. 992 [SSH] Barrett, D., Silverman, R., and R. Byrnes, "SSH, the 993 Secure Shell: The Definitive Guide, Second Edition, 994 O'Reilly and Associates", May 2005. 996 Authors' Addresses 998 David B. Nelson 999 Elbrys Networks, Inc. 1000 75 Rochester Avenue, Unit 3 1001 Portsmouth, NH 03801 1002 USA 1004 Email: d.b.nelson@comcast.net 1006 Greg Weber 1007 Individual Contributor 1008 Knoxville, TN 37932 1009 USA 1011 Email: gdweber@gmail.com 1013 Full Copyright Statement 1015 Copyright (C) The IETF Trust (2008). 1017 This document is subject to the rights, licenses and restrictions 1018 contained in BCP 78, and except as set forth therein, the authors 1019 retain all their rights. 1021 This document and the information contained herein are provided on an 1022 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1023 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1024 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1025 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1026 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1027 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1029 Intellectual Property 1031 The IETF takes no position regarding the validity or scope of any 1032 Intellectual Property Rights or other rights that might be claimed to 1033 pertain to the implementation or use of the technology described in 1034 this document or the extent to which any license under such rights 1035 might or might not be available; nor does it represent that it has 1036 made any independent effort to identify any such rights. Information 1037 on the procedures with respect to rights in RFC documents can be 1038 found in BCP 78 and BCP 79. 1040 Copies of IPR disclosures made to the IETF Secretariat and any 1041 assurances of licenses to be made available, or the result of an 1042 attempt made to obtain a general license or permission for the use of 1043 such proprietary rights by implementers or users of this 1044 specification can be obtained from the IETF on-line IPR repository at 1045 http://www.ietf.org/ipr. 1047 The IETF invites any interested party to bring to its attention any 1048 copyrights, patents or patent applications, or other proprietary 1049 rights that may cover technology that may be required to implement 1050 this standard. Please address the information to the IETF at 1051 ietf-ipr@ietf.org.