RFC 9105

A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)

📅 published August 2021, from ietf

RFC 9105: A YANG Data Model for TACACS+ 💖

Okay bestie, here's the paperwork vibe check 📋✨ This is RFC 9105, titled A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+). It's a Standards Track doc from August 2021, published under ISSN 2070-1721. The authors are B. Wu (editor), G. Zheng, and M. Wang (editor), all from Huawei 🌸 It doesn't list anything it obsoletes or updates, so it's standing on its own.

Abstract 🦋

So this doc defines a TACACS+ client YANG module. It augments the System Management data model from RFC 7317 so devices can use TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA) 🔐 It's a standard module, but it does not endorse the security mechanisms of the TACACS+ protocol (RFC 8907), and TACACS+ MUST be used within a secure deployment. Please don't skip that part 😭

The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342 💅

Status of This Memo 🌈

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🎀

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9105 ✨

Copyright (c) 2021 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 (https://trustee.ietf.org/license-info) as they stand on the publication date. Read these carefully, because they spell out your rights and restrictions for this document 🧾 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

Table of Contents 🍓

1.  Introduction
2.  Conventions Used in This Document
  2.1.  Tree Diagrams
3.  Design of the TACACS+ Data Model
4.  TACACS+ Client Module
5.  Security Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Appendix A.  Example TACACS+ Authentication Configuration
Acknowledgments
Authors' Addresses

1. Introduction ✨

Okay, so this doc defines a YANG module that augments the System Management data model from [RFC7317] to support configuring and managing TACACS+ clients 🧚

TACACS+ [RFC8907] gives device administration for routers, network access servers, and other networked devices through one or more centralized servers. Very main character energy 👑

The System Management data model [RFC7317] already has its own separate features for local and RADIUS authentication:

  • User Authentication Model: Defines a list of usernames with associated passwords, plus a config leaf that decides the order in which local or RADIUS authentication gets used.
  • RADIUS Client Model: Defines a list of RADIUS servers that a device uses for centralized user authentication.

So the System Management data model gets augmented with the TACACS+ YANG module from this document. That lets TACACS+ servers show up as an alternative to RADIUS servers 🦋

You can use this YANG module with network management protocols like the Network Configuration Protocol (NETCONF) [RFC6241] 💻

The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342] 🫶

2. Conventions Used in This Document 📖

Here's the vibe on keywords 🔑 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, as shown here. Lowercase is just regular English, no cap 💅

The following terms are defined in [RFC6241] and used in this specification:

  • configuration data
  • state data

The following terms are defined in [RFC7950] and used in this specification:

  • augment
  • data model
  • data node

The terminology for describing YANG data models is found in [RFC7950] 🌸

2.1. Tree Diagrams 🌳

The tree diagram in this document follows the notation defined in [RFC8340] 🧠

3. Design of the TACACS+ Data Model 🎀

This module configures a TACACS+ client on a device so it can work with centralized authentication, authorization, and accounting servers. Quick recap: authentication checks a user's username and password, authorization lets the user access and run commands at the privilege levels assigned to them, and accounting tracks what a user has been doing once they've gotten into the device 📝

The ietf-system-tacacs-plus module augments the /sys:system path, which is defined in the ietf-system module, with the contents of the tacacs-plus grouping. So a device can use local, RADIUS, or TACACS+ authentication to validate users trying to access the router through several mechanisms, like a command line interface or a web-based user interface 💅

The server list sits directly under the tacacs-plus container. It holds a list of TACACS+ servers and uses server-type to tell apart Authentication, Authorization, and Accounting (AAA) services. The list of servers is there for redundancy, so you're not stuck if one goes down 🫶

Most of the parameters in the server list come straight from the TACACS+ protocol [RFC8907], and some are derived from the various implementations by network equipment manufacturers. For example, when there are multiple interfaces connected to the TACACS+ client or server, the source address of outgoing TACACS+ packets can be specified. Or the source address can be set through the interface IP address setting, or derived from the outbound interface in the local Forwarding Information Base (FIB). If the TACACS+ server lives in a Virtual Private Network (VPN), you need to specify a VPN Routing and Forwarding (VRF) instance 🌈

The statistics container under the server list is a collection of read-only counters for messages sent and received from a configured server 📊

Here's the structure of the YANG module for the TACACS+ client 👑

module: ietf-system-tacacs-plus
  augment /sys:system:
    +--rw tacacs-plus
       +--rw server* [name]
          +--rw name                      string
          +--rw server-type               tacacs-plus-server-type
          +--rw address                   inet:host
          +--rw port?                     inet:port-number
          +--rw (security)
          |  +--:(obfuscation)
          |     +--rw shared-secret?      string
          +--rw (source-type)?
          |  +--:(source-ip)
          |  |  +--rw source-ip?          inet:ip-address
          |  +--:(source-interface)
          |     +--rw source-interface?   if:interface-ref
          +--rw vrf-instance?
          |       -> /ni:network-instances/network-instance/name
          +--rw single-connection?        boolean
          +--rw timeout?                  uint16
          +--ro statistics
             +--ro connection-opens?      yang:counter64
             +--ro connection-closes?     yang:counter64
             +--ro connection-aborts?     yang:counter64
             +--ro connection-failures?   yang:counter64
             +--ro connection-timeouts?   yang:counter64
             +--ro messages-sent?         yang:counter64
             +--ro messages-received?     yang:counter64
             +--ro errors-received?       yang:counter64
             +--ro sessions?              yang:counter64

4. TACACS+ Client Module ✨

okay so this is where the actual YANG module lives 🎀 it pulls in typedefs from [RFC6991] (the common YANG data types, bestie 💅), and it also borrows the interface typedef from [RFC8343], the leafref to VRF instance from [RFC8529], and the default-deny-all extension statement from [RFC8341]. it's giving reuse, no cap 🫶

<CODE BEGINS> file "ietf-system-tacacs-plus@2021-08-05.yang"
module ietf-system-tacacs-plus {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-system-tacacs-plus";
  prefix sys-tcs-plus;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-network-instance {
    prefix ni;
    reference
      "RFC 8529: YANG Data Model for Network Instances";
  }
  import ietf-interfaces {
    prefix if;
    reference
      "RFC 8343: A YANG Data Model for Interface Management";
  }
  import ietf-system {
    prefix sys;
    reference
      "RFC 7317: A YANG Data Model for System Management";
  }
  import ietf-netconf-acm {
    prefix nacm;
    reference
      "RFC 8341: Network Configuration Access Control Model";
  }

  organization
    "IETF OPSAWG (Operations and Management Area Working Group)";
  contact
    "WG Web:   <http://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>

     Editor: Bo Wu <lana.wubo@huawei.com>
     Editor: Guangying Zheng <zhengguangying@huawei.com>";
  description
    "This module provides configuration of TACACS+ client.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC 9105; see the
     RFC itself for full legal notices.";

  revision 2021-08-05 {
    description
      "Initial revision.";
    reference
      "RFC 9105: A YANG Data Model for Terminal Access Controller
       Access-Control System Plus (TACACS+)";
  }

  typedef tacacs-plus-server-type {
    type bits {
      bit authentication {
        description
          "Indicates that the TACACS+ server is providing
           authentication services.";
      }
      bit authorization {
        description
          "Indicates that the TACACS+ server is providing
           authorization services.";
      }
      bit accounting {
        description
          "Indicates that the TACACS+ server is providing accounting
           services.";
      }
    }
    description
      "tacacs-plus-server-type can be set to
       authentication/authorization/accounting
       or any combination of the three types.";
  }

  identity tacacs-plus {
    base sys:authentication-method;
    description
      "Indicates AAA operation using TACACS+.";
    reference
      "RFC 8907: The TACACS+ Protocol";
  }

  grouping statistics {
    description
      "Grouping for TACACS+ statistics attributes.";
    container statistics {
      config false;
      description
        "A collection of server-related statistics objects.";
      leaf connection-opens {
        type yang:counter64;
        description
          "Number of new connection requests sent to the server,
           e.g., socket open.";
      }
      leaf connection-closes {
        type yang:counter64;
        description
          "Number of connection close requests sent to the server,
           e.g., socket close.";
      }
      leaf connection-aborts {
        type yang:counter64;
        description
          "Number of aborted connections to the server.  These do
           not include connections that are closed gracefully.";
      }
      leaf connection-failures {
        type yang:counter64;
        description
          "Number of connection failures to the server.";
      }
      leaf connection-timeouts {
        type yang:counter64;
        description
          "Number of connection timeouts to the server.";
      }
      leaf messages-sent {
        type yang:counter64;
        description
          "Number of messages sent to the server.";
      }
      leaf messages-received {
        type yang:counter64;
        description
          "Number of messages received from the server.";
      }
      leaf errors-received {
        type yang:counter64;
        description
          "Number of error messages received from the server.";
      }
      leaf sessions {
        type yang:counter64;
        description
          "Number of TACACS+ sessions completed with the server.
           If the Single Connection Mode was NOT enabled, the number
           of sessions is the same as the number of
           'connection-closes'.  If the Mode was enabled, a single
           TCP connection may contain multiple TACACS+ sessions.";
      }
    }
  }

  grouping tacacs-plus {
    description
      "Grouping for TACACS+ attributes.";
    container tacacs-plus {
      must "not(derived-from-or-self(../sys:authentication"
         + "/sys:user-authentication-order, 'tacacs-plus'))"
         + " or bit-is-set(server/server-type,'authentication')" {
        error-message "When 'tacacs-plus' is used as a system"
                    + " authentication method, a TACACS+"
                    + " authentication server must be configured.";
        description
          "When 'tacacs-plus' is used as an authentication method,
           a TACACS+ server must be configured.";
      }
      description
        "Container for TACACS+ configurations and operations.";
      list server {
        key "name";
        ordered-by user;
        description
          "List of TACACS+ servers used by the device.";
        leaf name {
          type string;
          description
            "An arbitrary name for the TACACS+ server.";
        }
        leaf server-type {
          type tacacs-plus-server-type;
          mandatory true;
          description
            "Server type: authentication/authorization/accounting and
             various combinations.";
        }
        leaf address {
          type inet:host;
          mandatory true;
          description
            "The address of the TACACS+ server.";
        }
        leaf port {
          type inet:port-number;
          default "49";
          description
            "The port number of TACACS+ Server port.";
        }
        choice security {
          mandatory true;
          description
            "Security mechanism between TACACS+ client and server.
             This is modeled as a YANG 'choice' so that it can be
             augmented by a YANG module in a backwards-compatible
             manner.";
          case obfuscation {
            leaf shared-secret {
              type string {
                length "1..max";
              }
              nacm:default-deny-all;
              description
                "The shared secret, which is known to both the
                 TACACS+ client and server.  TACACS+ server
                 administrators SHOULD configure a shared secret with
                 a minimum length of 16 characters.
                 It is highly recommended that this shared secret is
                 at least 32 characters long and sufficiently complex
                 with a mix of different character types,
                 i.e., upper case, lower case, numeric, and
                 punctuation.  Note that this security mechanism is
                 best described as 'obfuscation' and not 'encryption'
                 as it does not provide any meaningful integrity,
                 privacy, or replay protection.";
              reference
                "RFC 8907: The TACACS+ Protocol";
            }
          }
        }
        choice source-type {
          description
            "The source address type for outbound TACACS+ packets.";
          case source-ip {
            leaf source-ip {
              type inet:ip-address;
              description
                "Specifies source IP address for TACACS+ outbound
                 packets.";
            }
          }
          case source-interface {
            leaf source-interface {
              type if:interface-ref;
              description
                "Specifies the interface from which the IP address
                 is derived for use as the source for the outbound
                 TACACS+ packet.";
            }
          }
        }
        leaf vrf-instance {
          type leafref {
            path "/ni:network-instances/ni:network-instance/ni:name";
          }
          description
            "Specifies the VPN Routing and Forwarding (VRF) instance
             to use to communicate with the TACACS+ server.";
          reference
            "RFC 8529: YANG Data Model for Network Instances";
        }
        leaf single-connection {
          type boolean;
          default "false";
          description
            "Indicates whether the Single Connection Mode is enabled
             for the server.  By default, the Single Connection Mode
             is disabled.";
        }
        leaf timeout {
          type uint16 {
            range "1..max";
          }
          units "seconds";
          default "5";
          description
            "The number of seconds the device will wait for a
             response from each TACACS+ server before trying with a
             different server.";
        }
        uses statistics;
      }
    }
  }

  augment "/sys:system" {
    description
      "Augments the system model with the tacacs-plus model.";
    uses tacacs-plus;
  }
}
<CODE ENDS>

5. Security Considerations 🔐

Okay bestie, this part is SERIOUS, so read it carefully 🫶. The YANG module in this document is a schema for data that gets accessed over network management protocols like NETCONF [RFC6241] or RESTCONF [RFC8040]. For NETCONF, the bottom layer is the secure transport layer, and the transport every implementation has to support is Secure Shell (SSH) [RFC6242]. For RESTCONF, the bottom layer is HTTPS, and the must-support transport there is TLS [RFC8446].

The Network Configuration Access Control Model (NACM) [RFC8341] is how you lock things down. It lets you restrict particular NETCONF or RESTCONF users to a set of protocol operations and content that you've preconfigured. Main character access control energy 💅

Now the scary part 😭. Lots of data nodes in this module are writable, creatable, and deletable (that's config true, which is the default). In some network environments these nodes can be sensitive or vulnerable. If someone does a write operation (like edit-config) to them without proper protection, it can really mess up network operations. Here are the subtrees and data nodes, and why they're sensitive:

  • /system/tacacs-plus/server: This list holds the data nodes that control which TACACS+ servers the device uses. If an attacker gets unauthorized access to this list, they could take complete control of the device by pointing it at a compromised TACACS+ server. They could also mess with the counters to hide attacks on the device. Absolutely not, that's a disaster 💀
  • /system/tacacs-plus/server/shared-secret: This leaf holds the key that both the TACACS+ client and server know. If unauthorized folks can get to it, the device becomes vulnerable to attacks. That's why it's locked down with the "default-deny-all" access control from [RFC8341]. When you set it, it is highly recommended that the leaf is at least 32 characters long and complex enough to mix upper case, lower case, numeric, and punctuation characters. Make it a passphrase that feels like a sealed secret 🔑🌸

Last but not least, this document describes using TACACS+ for authentication, authorization, and accounting. That means it's vulnerable to every threat that exists for TACACS+ applications 😭. If you want the full breakdown of those threats, go read Section 10 of the TACACS+ protocol [RFC8907]. Stay safe out there 🦋

6. IANA Considerations 📋

IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:

URI:  urn:ietf:params:xml:ns:yang:ietf-system-tacacs-plus
Registrant Contact:  The IESG.
XML:  N/A, the requested URI is an XML namespace.

IANA has also registered the following YANG module in the "YANG Module Names" registry [RFC7950]:

Name:  ietf-system-tacacs-plus
Maintained by IANA:  N
Namespace:  urn:ietf:params:xml:ns:yang:ietf-system-tacacs-plus
Prefix:  sys-tcs-plus
Reference:  RFC 9105

7. References 📚

7.1. Normative References

These are the references you absolutely need to read to get the full picture 🧚

7.2. Informative References

And this one is just for extra context 🌈

Appendix A. Example TACACS+ Authentication Configuration 🎀

Here's an example where a TACACS+ authentication server instance gets configured. Copy the vibe, not the secret 🙈

  {
    "ietf-system:system": {
      "authentication": {
        "user-authentication-order": [tacacs-plus, local-users]
      }
      "tacacs-plus": {
        "server": [
          {
            "name": "tac_plus1",
            "server-type": "authentication",
            "address": "192.0.2.2",
            "shared-secret": "QaEfThUkO198010075460923+h3TbE8n",
            "source-ip": "192.0.2.12",
            "timeout": "10"
          }
        ]
      }
    }
  }

Acknowledgments 🫶

The authors wish to thank Alex Campbell, John Heasley, Ebben Aries, Alan DeKok, Joe Clarke, Tom Petch, Robert Wilton, and many others for their helpful comments and suggestions. Thank you all, you're literally the best 💖

Authors' Addresses ✨

Bo Wu (editor)
Huawei Technologies, Co., Ltd
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China

Email: lana.wubo@huawei.com


Guangying Zheng
Huawei Technologies, Co., Ltd
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China

Email: zhengguangying@huawei.com


Michael Wang (editor)
Huawei Technologies, Co., Ltd
Yuhua District
101 Software Avenue
Nanjing
210012
China

Email: wangzitao@huawei.com
📦 where this page comes from