RFC 5607

Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management

📅 published July 2009, from ietf

RFC 5607: RADIUS Authorization for NAS Management 🎀

Okay bestie, let's talk about RFC 5607. It's a Standards Track spec from July 2009, written by D. Nelson from Elbrys Networks, Inc. and G. Weber, who was writing as an Individual Contributor. It's all about RADIUS authorization for managing a Network Access Server (NAS). The title block doesn't list any "Obsoletes" or "Updates," so this one doesn't replace or change anything else. 💅✨

Abstract 🌸

So this doc defines RADIUS attributes for authorizing management access to a NAS. It supports both local and remote management, with granular access rights and management privileges. It also makes special provisions for remote management through Framed Management protocols, plus management access over a secure transport protocol. It's giving full control panel energy 😭🫶

Status of This Memo 🦋

This document specifies an Internet standards track protocol for the Internet community, and it requests discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 📚

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, because they describe your rights and restrictions with respect to this document. 🧾

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 🙈

Table of Contents 🍓

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Domain of Applicability  . . . . . . . . . . . . . . . . . . .  5
   5.  New Values for Existing RADIUS Attributes  . . . . . . . . . .  6
     5.1.  Service-Type . . . . . . . . . . . . . . . . . . . . . . .6
   6.  New RADIUS Attributes  . . . . . . . . . . . . . . . . . . . .  6
     6.1.  Framed-Management-Protocol . . . . . . . . . . . . . . . .  6
     6.2.  Management-Transport-Protection  . . . . . . . . . . . . . 9
     6.3.  Management-Policy-Id . . . . . . . . . . . . . . . . . . . 11
     6.4.  Management-Privilege-Level . . . . . . . . . . . . . . . . 13
   7.  Use with Dynamic Authorization . . . . . . . . . . . . . . . . 15
   8.  Examples of Attribute Groupings  . . . . . . . . . . . . . . . 15
   9.  Diameter Translation Considerations  . . . . . . . . . . . . . 17
   10. Table of Attributes  . . . . . . . . . . . . . . . . . . . . . 18
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
     12.1. General Considerations . . . . . . . . . . . . . . . . . . 20
     12.2. RADIUS Proxy Operation Considerations  . . . . . . . . . . 22
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     14.2. Informative References . . . . . . . . . . . . . . . . . . 23

1. Introduction 🌈

Okay so, [RFC2865] defines the NAS-Prompt (7) and Administrative (6) values of the Service-Type (6) Attribute. Both of these values give access to the interactive, text-based Command Line Interface (CLI) of the NAS. They were originally built to control access to the NAS's physical console port, which is most often a serial port. 🔌

Remote access to the CLI of the NAS has been around in NAS implementations for many years, using protocols like Telnet, Rlogin, and the remote terminal service of the Secure SHell (SSH). To tell local, physical console access apart from remote access, the NAS-Port-Type (61) Attribute is generally included in Access-Request and Access-Accept messages, along with the Service-Type (6) Attribute, to show the form of access. A NAS-Port-Type (61) Attribute with a value of Async (0) means a local serial port connection, while a value of Virtual (5) means a remote connection through a remote terminal protocol. This usage gives no selectivity among the different remote terminal protocols (e.g., Telnet, Rlogin, SSH, etc.). 🙄

Today, it's super common for network devices to support more than the two privilege levels for management access that the Service-Type (6) Attribute gives us, which are NAS-Prompt (7) (non-privileged) and Administrative (6) (privileged). Other management mechanisms are also used, like Web-based management, the Simple Network Management Protocol (SNMP), and the Network Configuration Protocol (NETCONF). To support these extra features, this specification defines attributes for Framed Management protocols, management protocol security, and management access privilege levels. Main character energy 👑

Remote management through the command line is carried over protocols like Telnet, Rlogin, and the remote terminal service of SSH. Since these protocols are mainly for delivering terminal or terminal emulation services, the term "Framed Management" is used to describe management protocols that support techniques other than the command line. These mechanisms usually format management information in a binary or textual encoding such as HTML, XML, or ASN.1/BER. Examples include Web-based management (HTML over HTTP or HTTPS), NETCONF (XML over SSH or BEEP or SOAP), and SNMP (SMI over ASN.1/BER). Command line interface, menu interface, or other text-based (e.g., ASCII or UTF-8) terminal emulation services are not considered Framed Management protocols. 🦋

2. Terminology 🧚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the official BCP 14 key words, so they carry real weight here. 📖

This document uses terminology from [RFC2865], [RFC2866], and [RFC5176]. 🧠

The term "integrity protection", as used in this document, is not the same as "authentication", as used in SNMP. Integrity protection requires the sharing of cryptographic keys, but it does not require authenticated principals. Integrity protection could be used, for example, with anonymous Diffie-Hellman key agreement. In SNMP, the proof of identity of the principals (authentication) gets mixed up with tamper-resistance of the protected messages (integrity). In this document, we assume that integrity protection and authentication are separate concerns. Authentication is part of the base RADIUS protocol. 🔐

SNMP uses the terms "auth" and "noAuth", as well as "priv" and "noPriv". There is no analog to auth or noAuth in this document. In this document, we are assuming that authentication always occurs when it is required, i.e., as a prerequisite to provisioning of access via an Access-Accept packet. ✅

3. Overview 💖

To support the authorization and provisioning of Framed Management access to managed entities, this document introduces a new value for the Service-Type (6) Attribute [RFC2865] and one new attribute. The new value for the Service-Type (6) Attribute is Framed-Management (18), used for remote device management via a Framed Management protocol. The new attribute is Framed-Management-Protocol (133), and its value specifies a particular protocol for use in the remote management session. 🎀

Two new attributes are introduced in this document to support granular management access rights or command privilege levels. The Management-Policy-Id (135) Attribute provides a text string that specifies a policy name of local scope, which is assumed to have been pre-provisioned on the NAS. Using an attribute to specify a pre-provisioned policy is similar to the Filter-Id (11) Attribute defined in [RFC2865] Section 5.11. 🗂️

Locally, the Management-Policy-Id (135) Attribute can be applied within the managed entity in a few ways: (a) as one of an enumeration of command privilege levels, (b) as a mapping into an SNMP Access Control Model, such as the View-Based Access Control Model (VACM) [RFC3415], or (c) as some other set of management access policy rules that is mutually understood by the managed entity and the remote management application. Examples are given in Section 8. 🍬

The Management-Privilege-Level (136) Attribute contains an integer-valued management privilege level indication. This attribute serves to modify or augment the management permissions provided by the NAS-Prompt (7) value of the Service-Type (6) Attribute, so it applies to CLI management. ⭐

To let management security requirements be specified, the Management-Transport-Protection (134) Attribute is introduced. The value of this attribute indicates the minimum level of secure transport protocol protection required for provisioning NAS-Prompt (7), Administrative (6), or Framed-Management (18) service. 🔒

4. Domain of Applicability 🦋

Okay so most of the RADIUS attributes in this doc are super versatile 💖 They can set up both local and remote management access on NAS devices. The ones that handle remote access over Framed Management protocols and secure transports are a whole different vibe though 👀 They need special consideration. This doc doesn't go into how those protocols get wired up to a RADIUS client inside the NAS. There are still functional requirements for using Framed Management protocols and/or secure transport protocols correctly, and those requirements narrow down which protocols can even be considered for RADIUS. ✨

Here's the key part 🫶 The RADIUS client usually grabs the RADIUS user credentials from the secure transport protocol server or the Framed Management protocol server. So the protocol, and its implementation in the NAS, MUST support credential forms that work with the authentication methods RADIUS supports. No mismatch allowed, bestie 💅

RADIUS currently supports these user authentication methods, although more may show up later 🌈

The remote management protocols picked for RADIUS remote NAS management sessions (like the ones in Section 6.1) and the secure transport protocols picked to meet the protection requirements (as described in Section 6.2) obviously need to support user authentication methods that match the ones RADIUS already has 🎀 The RADIUS methods most likely to work with these protocols are Password, CHAP, and maybe HTTP Digest, with Password being the distinct common denominator 💜 Lots of secure transports support sturdier auth mechanisms like public key, but RADIUS has no public key support, except inside an EAP Method. The EAP applicability statement says EAP isn't meant to be used as an application-layer authentication mechanism, so using it with the mechanisms in this document is NOT RECOMMENDED 🙈 In some cases, Password might be the only compatible RADIUS authentication method available 😭

5. New Values for Existing RADIUS Attributes 🌸

5.1. Service-Type 🍓

The Service-Type (6) Attribute is defined in Section 5.6 of RFC 2865 [RFC2865]. This doc adds a brand new value for it, and here it is 👑

   18   Framed-Management

Here's what Framed-Management means:

   Framed-Management   A Framed Management protocol session should
                       be started on the NAS.

6. New RADIUS Attributes 💅

This document defines four new RADIUS attributes related to management authorization. Four whole new attributes, bestie, we're eating ✨

6.1. Framed-Management-Protocol 🧚

The Framed-Management-Protocol (133) Attribute tells you which application-layer management protocol to use for Framed Management access. It MAY be used in both Access-Request and Access-Accept packets. It always pairs with a Service-Type (6) Attribute set to Framed-Management (18) 🔥

It is RECOMMENDED that the NAS include a Framed-Management-Protocol (133) Attribute with the right value in an Access-Request packet, so the server knows what kind of management access is being asked for. It is further RECOMMENDED that the NAS also include a Service-Type (6) Attribute with the value Framed-Management (18) in that same Access-Request packet. The RADIUS server MAY use these attributes as a hint when it makes its authorization decision 🦋

The RADIUS server MAY include a Framed-Management-Protocol (133) Attribute in an Access-Accept packet that also has a Service-Type (6) Attribute set to Framed-Management (18). It does this when it wants to enforce a management access policy for the authenticated user that prefers one form of management access over the others 🌈

When a NAS gets a Framed-Management-Protocol (133) Attribute in an Access-Accept packet, it MUST deliver that specified form of management access or disconnect the session. If the NAS doesn't support the provisioned management application-layer protocol, or the management access protocol the user asked for doesn't match the Framed-Management-Protocol (133) Attribute in the Access-Accept packet, the NAS MUST treat the Access-Accept packet as if it had been an Access-Reject 😭

Here's a summary of the Framed-Management-Protocol (133) Attribute format. The fields go from left to right 🫶

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

  • 133 for Framed-Management-Protocol.

Length

  • 6

Value

  • The Value field is a four-octet enumerated value.
   1      SNMP
   2      Web-based
   3      NETCONF
   4      FTP
   5      TFTP
   6      SFTP
   7      RCP
   8      SCP

All other values are reserved for IANA allocation subject to the provisions of Section 11 🌟

The acronyms in the table above expand like this:

  • SNMP: Simple Network Management Protocol [RFC3411], [RFC3412], [RFC3413], [RFC3414], [RFC3415], [RFC3416], [RFC3417], [RFC3418].
  • Web-based: Use of an embedded web server in the NAS for management via a generic web browser client. The interface shown to the admin may be graphical, tabular, or textual. The protocol is HTML over HTTP. The protocol may optionally be HTML over HTTPS, i.e., using HTTP over TLS [HTML] [RFC2616]. 🌸
  • NETCONF: Management via the NETCONF protocol using XML over supported transports (e.g., SSH, BEEP, SOAP). As secure transport profiles get defined for NETCONF, the list of transport options may expand [RFC4741], [RFC4742], [RFC4743], [RFC4744]. 💜
  • FTP: File Transfer Protocol, used to transfer configuration files to and from the NAS [RFC0959].
  • TFTP: Trivial File Transfer Protocol, used to transfer configuration files to and from the NAS [RFC1350].
  • SFTP: SSH File Transfer Protocol, used to securely transfer configuration files to and from the NAS. SFTP uses the services of SSH [SFTP]. See also Section 3.7, "SSH and File Transfers" of [SSH]. More info on the "sftp" program is usually in the online docs ("man" pages) of Unix systems. 🔐
  • RCP: Remote CoPy file copy utility (Unix-based), used to transfer configuration files to and from the NAS. See Section 3.7, "SSH and File Transfers", of [SSH]. More info on the "rcp" program is usually in the online docs ("man" pages) of Unix systems. 🍓
  • SCP: Secure CoPy file copy utility (Unix-based), used to transfer configuration files to and from the NAS. The "scp" program is a simple wrapper around SSH. It's basically a patched BSD Unix "rcp", which uses ssh to do the data transfer (instead of using "rcmd"). See Section 3.7, "SSH and File Transfers", of [SSH]. More info on the "scp" program is usually in the online docs ("man" pages) of Unix systems. 🦋

6.2. Management-Transport-Protection 🔐✨

okay so the Management-Transport-Protection (134) Attribute is giving "how secure do we need to be, bestie" 💅. It sets the minimum level of protection needed for a protected transport, whether the access is Framed or non-Framed Management access 🦋. The NAS is allowed to go above that level if it wants, which is extra credit 💖, but it can never go below it 🙅‍♀️. The NAS MAY provide a greater level of protection, but it MUST NOT provide a lower level of protection.

Non-Framed Management access counts as secure when the remote terminal session gets wrapped in some kind of protected transport, or tunnel 🌸. It can also mean an explicit secure mode is required, but only when the Framed Management protocol has an intrinsic secure mode of its own 🧚. This attribute does not apply to CLI access over a local serial port, or any other non-remote connection, because nobody's sneaking in through the cable on your desk 🙈.

Framed Management access works the same way. Secure means the application-layer management protocol is encapsulated in some form of protected transport, or tunnel. It may also mean an explicit secure mode is required, when the Framed Management protocol contains an intrinsic secure mode of operation 🫶.

A value of "No Protection (1)" means a secure transport protocol is not required, and the NAS SHOULD accept a connection over any transport associated with the application-layer management protocol 🍓. The bindings for management applications to transports live in the documents that specify those management application protocols. The same "No Protection" semantics are also conveyed by leaving this attribute out of an Access-Accept packet ✨.

This attribute doesn't pick the protected transport protocol, cipher suites, key agreement methods, or authentication methods. That kind of setup is beyond the scope of this document 🎀.

It is RECOMMENDED that the NAS include an appropriately valued Management-Transport-Protection (134) Attribute in an Access-Request packet, showing the level of transport protection being requested for the management access, when the RADIUS client has that information 💜. The RADIUS server MAY use this attribute as a hint when it makes its authorization decision 🔥.

The RADIUS server MAY include a Management-Transport-Protection (134) Attribute in an Access-Accept packet that also has a Service-Type (6) Attribute with a value of Framed-Management (18). It does this when it wants to enforce a management access security policy for the authenticated user that sets a minimum level of transport security 👑.

When a NAS gets a Management-Transport-Protection (134) Attribute in an Access-Accept packet, it MUST deliver the management access over a transport with equal or better protection characteristics, or disconnect the session 🚫. If the NAS doesn't support protected management transport protocols, or the protection it has available doesn't match the Management-Transport-Protection (134) Attribute in the Access-Accept packet, the NAS MUST treat the response packet as if it had been an Access-Reject 💀.

Here's how the attribute is laid out. The fields go from left to right 🌈:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

134 for Management-Transport-Protection.

Length

6

Value

The Value field is a four-octet enumerated value.

1      No-Protection
2      Integrity-Protection
3      Integrity-Confidentiality-Protection

All other values are reserved for IANA allocation, subject to the provisions of Section 11 📋.

Here's what each name means 🧠:

  • No-Protection: No transport protection is required. Accept connections over any supported transport.
  • Integrity-Protection: The management transport MUST provide Integrity Protection, i.e., protection from unauthorized modification, using a cryptographic checksum 🔒.
  • Integrity-Confidentiality-Protection: The management transport MUST provide both Integrity Protection and Confidentiality Protection. That means protection from unauthorized modification, using a cryptographic checksum, plus protection from unauthorized disclosure, using encryption 🤐.

How acceptable algorithms, modes, and credentials get configured or negotiated for the cryptographic protection in protected management transports is outside the scope of this document. Lots of those mechanisms already have standardized ways to configure and manage keys 🔑.

6.3. Management-Policy-Id 📜💖

The Management-Policy-Id (135) Attribute names the management access policy for this user 🎀. Zero or one Management-Policy-Id (135) Attributes MAY be sent in an Access-Accept packet. Naming the policy lets it be used across different NASes without anyone worrying about implementation details 🧚.

The named policy can express several forms of management access rules, but defining those rules is beyond the scope of this document 🌸. The management access policy MAY be applied contextually, based on the kind of management access method. For example, some named policies might only be valid for NAS-Prompt (7) services, and others might only be valid for SNMP 🍓.

The management access policy named in this attribute, received in an Access-Accept packet, MUST be applied to the session that the Access-Accept authorizes. If the NAS supports this attribute but the policy name is unknown, or if the RADIUS client can tell that the policy rules are incorrectly formatted, the NAS MUST treat the Access-Accept packet as if it had been an Access-Reject 🚨.

There's no defined precedence for multiple occurrences of the Management-Policy-Id (135) Attribute, so NAS behavior in that case is undefined 🤷‍♀️. That's why two or more occurrences of this attribute SHOULD NOT be included in an Access-Accept or CoA-Request (Change-of-Authorization) packet. Unless some precedence relationship gets defined later, multi-vendor interoperability can't be guaranteed when using multiple instances of this attribute in a single Access-Accept or CoA-Request packet 💅.

The content of this attribute is expected to be the name of a management access policy with local significance to the NAS, inside a namespace that also has significance to the NAS. This works a lot like the Filter-Id (11) Attribute 🦋. The policy names and rules are committed to the NAS's local configuration data store, and they get provisioned by means beyond the scope of this document, such as SNMP, NETCONF, or CLI ✨.

The namespace for Management-Policy-Id (135) is simple and monolithic. It has no explicit or implicit structure or hierarchy. In the text string "example.com", the "." (period or dot) is just another character 🙃. Text string matching is expected to happen without parsing the string into any sub-fields 💜.

Stuffing this simple name with multi-part specifiers, like Access=remote or Level=7, is likely to hurt multi-vendor interoperability, so it SHOULD NOT be done 🙅‍♀️. If a simple, unstructured policy name isn't enough, it is RECOMMENDED to use a Vendor Specific (26) Attribute instead of overloading the semantics of Management-Policy-Id 🫶.

Here's the attribute layout. The fields go from left to right 🌈:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  Text ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

135 for Management-Policy-Id.

Length

>= 3

Text

The Text field is one or more octets, and its contents are implementation dependent. It's meant to be human readable, and the contents MUST NOT be parsed by the receiver. The contents can only be used to look up locally defined policies 🔍. It is RECOMMENDED that the message contain UTF-8 encoded 10646 [RFC3629] characters 🌷.

6.4. Management-Privilege-Level 💖

okay bestie, so the Management-Privilege-Level (136) Attribute is how you say "this user gets THIS privilege level for management access" 🔐 It's an integer, and lots of NASes already use numbered privilege levels. What each number actually grants is up to the implementation, so it's not standardized. It MAY be used in both Access-Request and Access-Accept packets ✨

The mapping from integer values to specific sets of management access rights or permissions on the NAS is vendor and implementation specific 🛠️ It's often user-configurable too. It's RECOMMENDED that greater numeric values imply greater privilege, but ngl, it would be a mistake to assume that always holds 💀

The management access level in this attribute, received in an Access-Accept packet, MUST be applied to the session authorized by the Access-Accept. And if the NAS supports this attribute but the privilege level is unknown, the NAS MUST treat the Access-Accept packet as if it had been an Access-Reject 🙅‍♀️

Here's the layout. The fields go left to right 👀

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |             Value
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Value (cont)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 136 for Management-Privilege-Level.
  • Length: 6.
  • Value: a four-octet Integer, denoting a management privilege level.

It is RECOMMENDED to limit use of the Management-Privilege-Level (136) Attribute to sessions where the Service-Type (6) Attribute is NAS-Prompt (7) (not Administrative) 🎀 Usually NASes treat NAS-Prompt as the minimal privilege CLI service and Administrative as full privilege. Using this attribute with NAS-Prompt (7) will effectively increase the minimum privilege level. On the flip side, it is NOT RECOMMENDED to use it with Administrative (6), since that may mean decreasing the maximum privilege level 😭

It is NOT RECOMMENDED to use the Management-Privilege-Level (136) Attribute together with a Management-Policy-Id (135) Attribute, or for management access methods other than interactive CLI 🙈 The behavior from that kind of overlay isn't defined by this document. Without further specification, it's likely to cause unexpected behaviors, especially in multi-vendor environments.

7. Use with Dynamic Authorization 🦋

It is entirely OPTIONAL for the NAS management authorization attributes in this document to be used with the Dynamic Authorization extensions to RADIUS [RFC5176]. When that happens, those attributes MAY be used as listed in the Table of Attributes in Section 10 ✨

Some guidance on identifying existing management sessions on a NAS for Dynamic Authorization is useful 🔍 The primary session identifiers SHOULD be User-Name (1) and Service-Type (6). But when that info alone doesn't uniquely identify a session, a NAS supporting Dynamic Authorization SHOULD keep one or more internal session identifiers that can be represented as RADIUS attributes. Examples include Acct-Session-Id (44), Acct-Multi-Session-Id (50), NAS-Port (5), or NAS-Port-Id (87). For remote management sessions, common identifier values might be things like the remote IP address and remote TCP port number, or the file descriptor for the open socket. Any of these is obviously transient, so implementations SHOULD take care to avoid and/or properly handle duplicate or stale values 💅

For the session identification attributes to be available to the Dynamic Authorization Client, a NAS supporting Dynamic Authorization for management sessions SHOULD include those session identification attributes in the Access-Request message for each such session. More on how to use session identification attributes is in Section 3 of [RFC5176] 🫶

8. Examples of Attribute Groupings 🍓

Okay, time for the fun part, bestie. Here are some attribute combos to see how it all clicks together 🧚

  1. Unprotected CLI access, via the local console, to the "super-user" access level:
    • Service-Type (6) = Administrative (6)
    • NAS-Port-Type (61) = Async (0)
    • Management-Transport-Protection (134) = No-Protection (1)
  2. Unprotected CLI access, via a remote console, to the "super-user" access level:
    • Service-Type (6) = Administrative (6)
    • NAS-Port-Type (61) = Virtual (5)
    • Management-Transport-Protection (134) = No-Protection (1)
  3. CLI access, via a fully protected secure remote terminal service, to the non-privileged user access level:
    • Service-Type (6) = NAS-Prompt (7)
    • NAS-Port-Type (61) = Virtual (5)
    • Management-Transport-Protection (134) = Integrity-Confidentiality-Protection (3)
  4. CLI access, via a fully protected secure remote terminal service, to a custom management access level defined by a policy:
    • Service-Type (6) = NAS-Prompt (7)
    • NAS-Port-Type (61) = Virtual (5)
    • Management-Transport-Protection (134) = Integrity-Confidentiality-Protection (3)
    • Management-Policy-Id (135) = "Network Administrator"
  5. CLI access, via a fully protected secure remote terminal service, with a management privilege level of 15:
    • Service-Type (6) = NAS-Prompt (7)
    • NAS-Port-Type (61) = Virtual (5)
    • Management-Transport-Protection (134) = Integrity-Confidentiality-Protection (3)
    • Management-Privilege-Level (136) = 15
  6. SNMP access, using an Access Control Model specifier, such as a custom VACM View defined by a policy:
    • Service-Type (6) = Framed-Management (18)
    • NAS-Port-Type (61) = Virtual (5)
    • Framed-Management-Protocol (133) = SNMP (1)
    • Management-Policy-Id (135) = "SNMP Network Administrator View"

There is currently no standardized way of implementing this management policy mapping within SNMP. Such mechanisms are the topic of current research 🔬

  1. SNMP fully protected access:
    • Service-Type (6) = Framed-Management (18)
    • NAS-Port-Type (61) = Virtual (5)
    • Framed-Management-Protocol (133) = SNMP (1)
    • Management-Transport-Protection (134) = Integrity-Confidentiality-Protection (3)
  2. Web (HTTP/HTML) access:
    • Service-Type (6) = Framed-Management (18)
    • NAS-Port-Type (61) = Virtual (5)
    • Framed-Management-Protocol (133) = Web-based (2)
  3. Secure web access, using a custom management access level defined by a policy:
    • Service-Type (6) = Framed-Management (18)
    • NAS-Port-Type (61) = Virtual (5)
    • Framed-Management-Protocol (133) = Web-based (2)
    • Management-Transport-Protection (134) = Integrity-Confidentiality-Protection (3)
    • Management-Policy-Id (135) = "Read-only web access"

9. Diameter Translation Considerations 🌈

When these attributes are used in Diameter, they can be used as Diameter attribute-value pairs (AVPs) from the Code space 1-255 (the RADIUS attribute compatibility space). So no additional Diameter Code values get allocated. The data types and flag rules for the attributes are below 👑

                                 +---------------------+
                                 |    AVP Flag rules   |
                                 |----+-----+----+-----|----+
                                 |    |     SHOULD MUST|    |
Attribute Name        Value Type |MUST| MAY | NOT|  NOT|Encr|
---------------------------------|----+-----+----+-----|----|
Service-Type                     |    |     |    |     |    |
                      Enumerated | M  |  P  |    |  V  | Y  |
Framed-Management-Protocol       |    |     |    |     |    |
                      Enumerated | M  |  P  |    |  V  | Y  |
Management-Transport-Protection  |    |     |    |     |    |
                      Enumerated | M  |  P  |    |  V  | Y  |
Management-Policy-Id             |    |     |    |     |    |
                      UTF8String | M  |  P  |    |  V  | Y  |
Management-Privilege-Level       |    |     |    |     |    |
                      Integer    | M  |  P  |    |  V  | Y  |
---------------------------------|----+-----+----+-----|----|

The attributes in this specification have no special translation requirements for Diameter to RADIUS or RADIUS to Diameter gateways. They're copied as is, except for changes relating to headers, alignment, and padding 🧁 See also [RFC3588], Section 4.1, and [RFC4005], Section 9.

What this specification says about the applicability of the attributes for RADIUS Access-Request packets applies in Diameter to AA-Request [RFC4005]. And what is said about Access-Accept applies in Diameter to AA-Answer messages that indicate success 💜

10. Table of Attributes 🧚

Okay bestie, this is the cheat sheet 📋 It shows which attributes can show up in which kinds of packets, and how many of each one you're allowed to pack in. Read the little codes like a menu 💅

Access Messages
Request Accept Reject Challenge  #     Attribute
---------------------------------------------------------------------
0-1     0-1      0        0     133   Framed-Management-Protocol
0-1     0-1      0        0     134   Management-Transport-Protection
0       0-1      0        0     135   Management-Policy-Id
0       0-1      0        0     136   Management-Privilege-Level
Accounting Messages
Request Response   #     Attribute
---------------------------------------------------------------------
0-1     0         133   Framed-Management-Protocol
0-1     0         134   Management-Transport-Protection
0-1     0         135   Management-Policy-Id
0-1     0         136   Management-Privilege-Level



Change-of-Authorization Messages
Request  ACK   NAK   #     Attribute
--------------------------------------------------------------------
0       0     0     133   Framed-Management-Protocol
0       0     0     134   Management-Transport-Protection
0-1     0     0     135   Management-Policy-Id (Note 1)
0-1     0     0     136   Management-Privilege-Level (Note 1)


Disconnect Messages
Request  ACK   NAK   #     Attribute
---------------------------------------------------------------------
0        0     0     133   Framed-Management-Protocol
0        0     0     134   Management-Transport-Protection
0        0     0     135   Management-Policy-Id
0        0     0     136   Management-Privilege-Level

Now, Note 1 is the big one 👀 When these attributes are included in a CoA-Request, they represent an authorization change request. If one of them is left out of a CoA-Request, the NAS assumes the value stays unchanged. And any attributes that are included in a CoA-Request replace all existing values of the same attribute(s). Main character energy 💖

Here's what the codes mean:

    0    This attribute MUST NOT be present in a packet.
    0+   Zero or more instances of this attribute MAY be present in
         a packet.
    0-1  Zero or one instance of this attribute MAY be present in
         a packet.
    1    Exactly one instance of this attribute MUST be present in
         a packet.

11. IANA Considerations 🌈

Okay so IANA has assigned some numbers for us ✨ They live in the RADIUS Attribute Types registry, and here's what's new:

  • New enumerated value for the existing Service-Type Attribute:
    • Framed-Management (18)
  • New RADIUS Attribute Types:
    • Framed-Management-Protocol (133)
    • Management-Transport-Protection (134)
    • Management-Policy-Id (135)
    • Management-Privilege-Level (136)

The enumerated values for the newly assigned RADIUS Attribute Types were given out at the same time as the new Attribute Types, so they're all set together 🎀

For the Framed-Management-Protocol Attribute:

      1      SNMP
      2      Web-based
      3      NETCONF
      4      FTP
      5      TFTP
      6      SFTP
      7      RCP
      8      SCP

For the Management-Transport-Protection Attribute:

      1      No-Protection
      2      Integrity-Protection
      3      Integrity-Confidentiality-Protection

Any future enumerated values for the RADIUS attributes in this document get handled as described in [RFC3575], with the extra requirement of a published specification 📜

12. Security Considerations 🔥

Okay, this section is serious business, so no skipping 😭

12.1. General Considerations

This specification describes how RADIUS and Diameter are used to handle authentication, authorization, and accounting for management access to devices within networks 🛡️ RADIUS threats and security issues for this application are described in [RFC3579] and [RFC3580], and security issues encountered in roaming are described in [RFC2607]. For Diameter, the security issues for this application are described in [RFC4005] and [RFC4072].

This document defines new attributes that can go inside existing RADIUS packets, which may be protected as described in [RFC3579] and [RFC5176]. In Diameter, the attributes are protected as specified in [RFC3588]. Go read those documents for the full tea ☕

The security mechanisms in RADIUS and Diameter are focused on stopping an attacker from spoofing packets or modifying them in transit. They do not stop an authorized RADIUS/Diameter server or proxy from inserting attributes with malicious intent 💀

A legacy NAS may not recognize the attributes in this document that supplement the provisioning of CLI management access. If the value of the Service-Type Attribute is NAS-Prompt or Administrative, the legacy NAS may silently discard such attributes, while still letting the user into the CLI management interface(s) of the NAS. This can lead to users improperly getting authorized management access to the NAS, or access with greater rights than were intended. RADIUS servers SHOULD attempt to figure out whether or not the NAS supports these attributes before sending them in an Access-Accept message that provisions CLI access.

It's possible that some NAS implementations can't tell the protection properties of the underlying transport protocol, as specified by the Management-Transport-Protection Attribute 🥺 This might be a limit of the standard application programming interface of the underlying transport implementation, or of how the transport got integrated into the NAS implementation. Either way, NASes conforming to this specification that can't determine the protection state of the remote management connection MUST treat an Access-Accept message containing a Management-Transport-Protection Attribute with a value other than No-Protection (1) as if it were an Access-Reject message, unless local policy configuration specifically overrides this.

Using the No-Protection (1) option for the Management-Transport-Protection (134) Attribute is NOT RECOMMENDED in any deployment where secure management or configuration is required 🚫

12.2. RADIUS Proxy Operation Considerations

The device management access authorization attributes in this document come with some considerations when used in RADIUS proxy environments 👀 These considerations are no different from the ones that already exist in RFC 2865 [RFC2865] for the Service-Type Attribute values of Administrative and NAS-Prompt.

Most RADIUS proxy environments are also multi-party environments. In multi-party proxy environments it matters a lot to know which entities have the authority to provision management access to the edge devices (the NASes), and which entities only have authority to provision network access services of various sorts 🧐

It may be important for NAS operators to make sure that access to the CLI, or other management interfaces of the NAS, is only provisioned to their own employees or contractors. One way for the NAS to enforce this is to use only local, non-proxy RADIUS servers for management access requests. Proxy RADIUS servers could be used for non-management access requests, based on local policy. This "bifurcation" of RADIUS authentication and authorization is a simple case of separate administrative realms 🌸 The NAS may be designed to keep separate lists of RADIUS servers for management AAA use and for non-management AAA use.

Another way to enforce this would be for the first-hop RADIUS proxy server, which is operated by the owner of the NAS, to filter out any RADIUS attributes that provision management access rights coming from "up-stream" proxy servers not operated by the NAS owner. Access-Accept messages that provision such locally unauthorized management access MAY be treated as if they were an Access-Reject by the first-hop proxy server 🚧

There's also an extra exposure in proxy deployments: sensitive user credentials, e.g., passwords, are likely to be available in cleartext at each of the proxy servers. Encrypted or hashed credentials don't have this risk, but password authentication is a very commonly used mechanism for management access authentication, and in RADIUS passwords are only protected on a hop-by-hop basis. Malicious proxy servers could misuse this sensitive information 😱

None of these issues are a concern when all the RADIUS servers, local and proxy, used by the NAS are under the sole administrative control of the NAS owner 💜

13. Acknowledgments 🫶

Huge thanks to all the reviewers: Bernard Aboba, Alan DeKok, David Harrington, Mauricio Sanchez, Juergen Schoenwaelder, Hannes Tschofenig, Barney Wolff, and Glen Zorn 🎀

14. References 📚

14.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
           "Remote Authentication Dial In User Service (RADIUS)",
           RFC 2865, June 2000.

[RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
           10646", STD 63, RFC 3629, November 2003.

14.2. Informative References 📚

okay bestie, these are the extra reads that back up the whole doc. the author-date stuff is listed exactly the way it's written, so nothing gets mangled 🫶

[HTML]     Raggett, D., Le Hors, A., and I. Jacobs, "The HTML 4.01
           Specification, W3C", December 1999.

[RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
           STD 9, RFC 959, October 1985.

[RFC1350]  Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
           RFC 1350, July 1992.

[RFC2607]  Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
           Implementation in Roaming", RFC 2607, June 1999.

[RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
           Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
           Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
           Architecture for Describing Simple Network Management
           Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
           December 2002.

[RFC3412]  Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
           "Message Processing and Dispatching for the Simple Network
           Management Protocol (SNMP)", STD 62, RFC 3412,
           December 2002.

[RFC3413]  Levi, D., Meyer, P., and B. Stewart, "Simple Network
           Management Protocol (SNMP) Applications", STD 62,
           RFC 3413, December 2002.

[RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
           (USM) for version 3 of the Simple Network Management
           Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

[RFC3415]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
           Access Control Model (VACM) for the Simple Network
           Management Protocol (SNMP)", STD 62, RFC 3415,
           December 2002.

[RFC3416]  Presuhn, R., "Version 2 of the Protocol Operations for the
           Simple Network Management Protocol (SNMP)", STD 62,
           RFC 3416, December 2002.

[RFC3417]  Presuhn, R., "Transport Mappings for the Simple Network
           Management Protocol (SNMP)", STD 62, RFC 3417,
           December 2002.

[RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
           Simple Network Management Protocol (SNMP)", STD 62,
           RFC 3418, December 2002.

[RFC3575]  Aboba, B., "IANA Considerations for RADIUS (Remote
           Authentication Dial In User Service)", RFC 3575,
           July 2003.

[RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
           Dial In User Service) Support For Extensible
           Authentication Protocol (EAP)", RFC 3579, September 2003.

[RFC3580]  Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
           "IEEE 802.1X Remote Authentication Dial In User Service
           (RADIUS) Usage Guidelines", RFC 3580, September 2003.

[RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
           Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
           "Diameter Network Access Server Application", RFC 4005,
           August 2005.

[RFC4072]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
           Authentication Protocol (EAP) Application", RFC 4072,
           August 2005.

[RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,
           December 2006.

[RFC4742]  Wasserman, M. and T. Goddard, "Using the NETCONF
           Configuration Protocol over Secure SHell (SSH)", RFC 4742,
           December 2006.

[RFC4743]  Goddard, T., "Using NETCONF over the Simple Object Access
           Protocol (SOAP)", RFC 4743, December 2006.

[RFC4744]  Lear, E. and K. Crozier, "Using the NETCONF Protocol over
           the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744,
           December 2006.

[RFC5176]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
           Aboba, "Dynamic Authorization Extensions to Remote
           Authentication Dial In User Service (RADIUS)", RFC 5176,
           January 2008.

[SFTP]     Galbraith, J. and O. Saarenmaa, "SSH File Transfer
           Protocol", Work in Progress, July 2006.

[SSH]      Barrett, D., Silverman, R., and R. Byrnes, "SSH, the
           Secure Shell: The Definitive Guide, Second Edition,
           O'Reilly and Associates", May 2005.

Authors' Addresses 🎀

these are the people who wrote it, so give them some love 💜

David B. Nelson
Elbrys Networks, Inc.
282 Corporate Drive
Portsmouth, NH  03801
USA

EMail: dnelson@elbrysnetworks.com


Greg Weber
Individual Contributor
Knoxville, TN  37932
USA

EMail: gdweber@gmail.com
📦 where this page comes from