<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="utf-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-opsawg-secure-tacacs-yang-13" number="9950" category="std" updates="" xml:lang="en" consensus="true" submissionType="IETF" obsoletes="9105" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!--xml2rfc v2v3 conversion 3.29.0[rfced] The abbreviated title (appears in the running header in PDF output) and the abstract use "TACACS+ over TLS". The document title does not include "over TLS". Please review and let us know if any updates are needed for consistency. Document title: A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) Abbreviated title: YANG for TACACS+ over TLS Abstract: Specifically, this document defines a YANG module for TACACS+ over TLS 1.3. --> <!-- [rfced] Please also review the text after "YANG module for" in these sentences from the Abstract and Introduction. The phrasing is different; please confirm the meaning is correct/consistent for both. Abstract: Specifically, this document defines a YANG module for TACACS+ over TLS 1.3. Introduction: This document defines a YANG module for managing TACACS+ clients (Section 4), including TACACS+ over TLS 1.3 clients [I-D.ietf-opsawg-tacacs-tls13]. --> <front> <title abbrev="YANG for TACACS+ over TLS">A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)</title> <seriesInfoname="Internet-Draft" value="draft-ietf-opsawg-secure-tacacs-yang-13"/>name="RFC" value="9950"/> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair" role="editor"> <organization>Orange</organization> <address> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="BoWu">Wu" initials="B" surname="Wu"> <organization>Huawei Technologies</organization> <address> <email>mlana.wubo@huawei.com</email> </address> </author> <dateyear="2025" month="July" day="07"/> <area>Operations and Management</area> <workgroup>Operations and Management Area Working Group</workgroup>year="2026" month="March"/> <area>OPS</area> <workgroup>opsawg</workgroup> <keyword>TLS</keyword> <keyword>device management</keyword> <keyword>network operator</keyword> <keyword>provider network</keyword> <keyword>AAA</keyword> <keyword>authentication</keyword> <keyword>authorization</keyword> <keyword>accounting</keyword> <abstract><?line 40?><t>This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Specifically, this document defines a YANG module for TACACS+ over TLS 1.3.</t> <t>This document obsoletes RFC 9105.</t> </abstract> </front> <middle><?line 50?><section anchor="introduction"> <name>Introduction</name> <t>The System Management data model <xref target="RFC7317"/> defines separate functionality to support local and Remote AuthenticationDial InDial-In User Service (RADIUS) authentication:</t> <dl> <dt>User Authentication Model:</dt> <dd> <t>Defines a list of user names with associated passwords and a configuration leaf to decide the order in which local or RADIUS authentication is used.</t> </dd> <dt>RADIUS Client Model:</dt> <dd> <t>Defines a list of RADIUS servers used by a device for centralized user authentication.</t> </dd> </dl> <t><xref target="RFC9105"/> defines a YANG module ("ietf-system-tacacs-plus") that augments the System Management data model <xref target="RFC7317"/> for the management of Terminal Access Controller Access-Control System Plus (TACACS+) clients as an alternative to RADIUS servers <xref target="RFC2865"/>. Typically, the "ietf-system-tacacs-plus" module is used to configure a TACACS+ client on a device to support deployment scenarios with centralizedauthentication, authorization,Authentication, Authorization, andaccountingAccounting (AAA) servers.</t> <t>This document defines a YANG module for managing TACACS+ clients (<xref target="sec-module"/>), including TACACS+ over TLS 1.3 clients <xreftarget="I-D.ietf-opsawg-tacacs-tls13"/>.target="RFC9887"/>. This document obsoletes <xref target="RFC9105"/>.</t> <t>The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t> <section anchor="changes-since-rfc-9105"> <name>Changes Since RFC 9105</name> <t>The following changes have been made to <xref target="RFC9105"/>:</t> <ul spacing="normal"> <li><t>Add<t>Added support for TLS <xreftarget="I-D.ietf-opsawg-tacacs-tls13"/></t>target="RFC9887"/></t> </li> <li><t>Add<t>Added a constraint to ensure that the list of servers is unique per address/port number</t> </li> <li><t>Update<t>Updated the description of 'address' to be consistent with the type</t> </li> <li><t>Fix<t>Fixed amust'must' statement under 'tacacs-plus'</t> </li> <li><t>Fix<t>Fixed errors in the example provided inAppendix A of<xref section="A" target="RFC9105"/></t> </li> <li><t>Add<t>Added an example to illustrate the use ofVRF</t>VPN Routing and Forwarding (VRF)</t> </li> <li><t>Add<t>Added new examples to illustrate the use of TACACS+TLS data nodes</t> </li> </ul> <t>DetailedYANGchangesare listed in <xref target="sec-module"/>.</t> </section> <section anchor="editorial-note-to-be-removed-by-rfc-editor"> <name>Editorial Note (To be removed by RFC Editor)</name> <ul empty="true"> <li> <t>Note to the RFC Editor: This section is to be removed prior to publication.</t> </li> </ul> <t>This document contains placeholder values that needtobe replaced with finalized values at the time of publication. This note summarizes all ofthesubstitutions thatYANG module areneeded.</t> <t>Please apply the following replacements:</t> <ul spacing="normal"> <li> <t>XXXX --> the assigned RFC number for this I-D</t> </li> <li> <t>SSSS --> the assigned RFC number for <xref target="I-D.ietf-opsawg-tacacs-tls13"/></t> </li> <li> <t>TBD --> the assigned port numberlisted in <xrefsection="7" sectionFormat="of" target="I-D.ietf-opsawg-tacacs-tls13"/></t> </li> <li> <t>2024-12-11 --> the actual date of the publication of this document</t> </li> </ul>target="sec-module"/>.</t> </section> </section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> <t>The terminology for describing YANG data models is defined in <xref target="RFC7950"/>.</t> <t>The document uses the terms defined in <xref section="2" sectionFormat="of"target="I-D.ietf-opsawg-tacacs-tls13"/>target="RFC9887"/> and <xref section="3" sectionFormat="of" target="RFC8907"/>.</t> <t>'client' refers to a TACACS+ client, while 'server' refers to a TACACS+ server.</t> <section anchor="tree-diagrams"> <name>Tree Diagrams</name> <t>The treediagramdiagrams used in this documentfollowsfollow the notation defined in <xref target="RFC8340"/>.</t> </section> </section> <section anchor="design-of-the-tacacs-data-model"> <name>Design of the TACACS+ Data Model</name> <t>This module is used to configure a TACACS+ client on a device to support deployment scenarios with centralizedauthentication, authorization,Authentication, Authorization, andaccountingAccounting (AAA) servers. Authentication is used to validate a user's username and password, authorization allows the user to access and execute commands at various privilege levels assigned to the user, and accounting keeps track of the activity of a user who has accessed the device.</t> <t>The "ietf-system-tacacs-plus" module augments the '/sys:system' path defined in the "ietf-system" module with the contents of the 'tacacs-plus' grouping. Therefore, a device can use local, RADIUS, or TACACS+ authentication to validate users who attempt to access the device by several mechanisms, e.g., a command line interface or a web-based user interface.</t> <t>The 'server' list, which is directly under the 'tacacs-plus' container, holds a list of TACACS+ servers and uses 'server-type' to distinguish betweenAuthentication, Authorization, and Accounting (AAA)AAA services. The list of servers is for redundancy.</t> <t>When there are multiple interfaces connected to a TACACS+ client or server, the source address of outgoing TACACS+ packets could be specified, or the source address could be specified through the interface IP address setting or derived from the outbound interface from the local Forwarding Information Base (FIB). For a TACACS+ server located in a Virtual Private Network (VPN), a VPN Routing and Forwarding (VRF) instance needs to be specified.</t> <t>The 'statistics' container under the 'server' list is a collection of read-only counters for sent and received messages from a configured server.</t> <!-- [rfced] In Section 3, should the "augment" line be indented 2 spaces (as it would be if it were incorporated into a full tree diagram per Section 2 of 8340)? We would indent the other lines 2 spaces as well. We do not believe this would cause any issues with line length for the TXT output. --> <t>The YANG module for TACACS+ client has the structure shown in <xref target="tree-overview"/>.</t> <figure anchor="tree-overview"> <name>Tree Structure Overview</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ augment /sys:system: +--rw tacacs-plus +--rw client-credentials* [id] {credential-reference}? | +--rw id string | +--rw (auth-type)? | +--:(certificate) | | ... | +--:(raw-public-key) {tlsc:client-ident-raw-public-key}? | | ... | +--:(tls13-epsk) {tlsc:client-ident-tls13-epsk}? | ... +--rw server-credentials* [id] {credential-reference}? | +--rw id string | +--rw ca-certs! | | ... | +--rw ee-certs! | | ... | +--rw raw-public-keys! {tlsc:server-auth-raw-public-key}? | | ... | +--rw tls13-epsks? empty | {tlsc:server-auth-tls13-epsk}? +--rw server* [name] +--rw name string +--rw server-type | tacacs-plus-server-type +--rw domain-name? inet:domain-name +--rw sni-enabled? boolean +--rw address inet:host +--rw port inet:port-number +--rw (security) | +--:(tls) | | +--rw client-identity! | | | +--rw (ref-or-explicit)? | | | +--:(ref) | | | | +--rw credentials-reference? | | | | sys-tcs-plus:client-credentials-ref | | | | {credential-reference}? | | | +--:(explicit) | | | +--rw (auth-type)? | | | +--:(certificate) | | | | ... | | | +--:(raw-public-key) | | | | {tlsc:client-ident-raw-public-key}? | | | | ... | | | +--:(tls13-epsk) | | | {tlsc:client-ident-tls13-epsk}? | | | ... | | +--rw server-authentication | | | +--rw (ref-or-explicit)? | | | +--:(ref) | | | | +--rw credentials-reference? | | | | sys-tcs-plus:server-credentials-ref | | | | {credential-reference}? | | | +--:(explicit) | | | +--rw ca-certs! | | | | ... | | | +--rw ee-certs! | | | | ... | | | +--rw raw-public-keys! | | | | {tlsc:server-auth-raw-public-key}? | | | | ... | | | +--rw tls13-epsks? empty | | | {tlsc:server-auth-tls13-epsk} | | +--rw hello-params {tlscmn:hello-params}? | | +--rw tls-versions | | | +--rw min? identityref | | | +--rw max? identityref | | +--rw cipher-suites | | +--rw cipher-suite* | | tlscsa:tls-cipher-suite-algorithm | +--:(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 discontinuity-time? yang:date-and-time +--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 +--ro cert-errors? yang:counter64 +--ro rpk-errors? yang:counter64 {tlsc:server-auth-raw-public-key}?]]></artwork>]]></sourcecode> </figure> <t>Specifically, the module is designed to cover the following key requirements specified in <xreftarget="I-D.ietf-opsawg-tacacs-tls13"/>:</t>target="RFC9887"/>:</t> <ul spacing="normal"> <li> <t>Minimum TLS 1.3 <xref target="RFC8446"/> <bcp14>MUST</bcp14> be used for transport.</t> </li> <li> <t>Earlier TLS versions <bcp14>MUST NOT</bcp14> be used.</t> </li> <li> <t>The cipher suites offered or accepted <bcp14>SHOULD</bcp14> be configurable.</t> </li> <li> <t>Implementations <bcp14>MAY</bcp14> support Raw Public Keys (RPKs) and Pre-Shared Keys (PSKs).</t> </li> <li> <t>Implementations <bcp14>MUST</bcp14> support the ability to configure the server's domain name, so that it may be included in the TLS Server Name Indication (SNI) extension.</t> </li> </ul> <t>The following new data nodes are supported compared to <xref target="RFC9105"/>:</t> <dl> <dt>'client-credentials' and 'server-credentials':</dt> <dd><t>Defines<t>Define a set credentials that can be globally provisioned and then referenced under specific servers.</t> </dd> <dt>'domain-name':</dt> <dd> <!-- [rfced] Is "Section 3.3" correct here? We ask because we do not see "domain name" or "domain-name" in Section 3.3 of [RFC9887]. Is another section in [RFC9887] intended, perhaps Section 3.4.2? Current: 'domain-name': Provides a domain name of the server per Section 3.3 of [I-D.ietf-opsawg-tacacs-tls13]. This is the TLS TACACS+ server's domain name that is included in the SNI extension. This domain name is distinct from the IP address/hostname used for the underlying transport connection. --> <t>Provides a domain name of the server per <xref section="3.3" sectionFormat="of"target="I-D.ietf-opsawg-tacacs-tls13"/>.target="RFC9887"/>. This is the TLS TACACS+ server's domain name that is included in the SNI extension. This domain name is distinct from the IP address/hostname used for the underlying transport connection.</t> </dd> <dt>'sni-enabled':</dt> <dd> <t>Controls activation ofServer Name Indication (SNI)SNI (<xref section="3" sectionFormat="of" target="RFC6066"/>). This parameter can be used only if a domain name is provided.</t> </dd> <dt>'client-identity':</dt> <dd> <t>Specifies the identity credentials that the client may present when establishing a connection to a server. Client identities can be configured at the top level and then referenced for specific server instances. Alternatively, client identities can be configured explicitly under each server instance.</t> </dd> <dt>'server-authentication':</dt> <dd> <t>Specifies how a client authenticates servers. Server credentials can be configured at the top level and then referenced for specific server instances. Alternatively, client identities can be configured explicitly under each server instance.</t> </dd> <dt>'hello-params':</dt> <dd> <t>Controls TLS versions and cipher suites to be used when establishing TLS sessions.</t> </dd> <dt>'discontinuity-time':</dt> <dd> <t>The time of the most recent occasion at which the client suffered a discontinuity (a configuration action to reset all counters, re-initialization, etc.).</t> </dd> <dt>'cert-errors':</dt> <dd> <t>Number of connection failures due to certificate issues.</t> </dd> <dt>'rpk-errors':</dt> <dd> <t>Number of connection failures related to raw publickey related connection failures.</t>keys.</t> </dd> </dl> </section> <section anchor="sec-module"> <name>TACACS+ Client Module</name> <!-- [rfced] We note that RFCs 8446, 8907, 9105, and 6066 are cited in the YANG module, but they are not included in the text introducing the module (see below). Please let us know if these should be added. If they are added, please indicate which sentence to include them. Original: This YANG module uses types and groupings defined in [RFC6991], [RFC8341], [RFC8343], [RFC8529], [RFC9640], [RFC9641], [RFC9642], and [RFC9645]. The module augments [RFC7317]. The module also cites [RFC6520], [RFC9257], and [RFC9258]. --> <!-- [rfced] RFC 6991 has been obsoleted by RFC 9911. Would you like to replace RFC 6991 with RFC 9911? Note RFC 6991 is mentioned three times in the document (one time in the text introducing the YANG module in Section 4 and twice in the module itself). --> <!--[rfced] May we update the YANG module as shown in the following diff file? https://www.rfc-editor.org/authors/ietf-system-tacacs-plus@2026-03-13-rfcdiff.html This diff file compares the current module to the output of the formatting tool (using pyang to format the module as described on the IETF "YANG review tools" wiki page at https://wiki.ietf.org/group/ops/yang-review-tools). To be clear, with or without the formatting updates, the YANG module parses. --> <!-- [rfced] We note that the list of authors/editors within the YANG module does not match the list of authors/editors for the document (i.e., Guangying Zheng appears in list in YANG module but is not listed as an author for the document). Please let us know if any updates are necessary. Original: contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Editor: Mohamed Boucadair <mailto:mohamed.boucadair@orange.com> Author: Bo Wu <lana.wubo@huawei.com> Author: Guangying Zheng <zhengguangying@huawei.com>"; --> <!-- [rfced] This text does not parse. May we update as follows? Original: - added a constraint on the VRF with 'source-interface' is also provided Perhaps: - adds a constraint on the VRF with 'source-interface' --> <!-- [rfced] FYI - We updated "servers list" to "list of servers" here for clarity. Original: - requires that the servers list must be unique per address/port number. Perhaps: - requires that the list of servers must be unique per address/port number. --> <!-- [rfced] May we update this description clause as follows to improve clarity? The suggested text below is similar to phrasing used elsewhere in the document. Original: description "Server type: authentication/authorization/accounting and various combinations."; Perhaps: description "The server type can be authentication, authorization, accounting, or any combination of the three types."; --> <t>This YANG module uses types and groupings defined in <xref target="RFC6991"/>, <xref target="RFC8341"/>, <xref target="RFC8343"/>, <xref target="RFC8529"/>, <xref target="RFC9640"/>, <xref target="RFC9641"/>, <xref target="RFC9642"/>, and <xref target="RFC9645"/>.</t> <t>The module augments <xref target="RFC7317"/>.</t> <t>The module also cites <xref target="RFC6520"/>, <xref target="RFC9257"/>, and <xref target="RFC9258"/>.</t> <sourcecodetype="yang"><![CDATA[ <CODE BEGINS> file "ietf-system-tacacs-plus@2025-01-23.yang"type="yang" name="ietf-system-tacacs-plus@2026-03-13.yang" markers="true"><![CDATA[ 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-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"; } import ietf-interfaces { prefix if; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-network-instance { prefix ni; reference "RFC 8529: YANG Data Model for Network Instances"; } import ietf-crypto-types { prefix ct; reference "RFC 9640: YANG Data Types and Groupings for Cryptography"; } import ietf-truststore { prefix ts; reference "RFC 9641: A YANG Data Model for a Truststore"; } import ietf-keystore { prefix ks; reference "RFC 9642: A YANG Data Model for a Keystore"; } import ietf-tls-common { prefix tlscmn; reference "RFC 9645: YANG Groupings for TLS Clients and TLS Servers"; } import ietf-tls-client { prefix tlsc; reference "RFC 9645: YANG Groupings for TLS Clients and TLS Servers"; } organization "IETF OPSAWG (Operations and Management Area Working Group)"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Editor: Mohamed Boucadair <mailto:mohamed.boucadair@orange.com> Author: Bo Wu <lana.wubo@huawei.com> Author: Guangying Zheng <zhengguangying@huawei.com>"; description "This module provides management of TACACS+ clients. 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)20252026 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 Revised 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). All revisions of IETF and IANA published modules can be found at the YANG Parameters registry (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFCXXXX;9950; see the RFC itself for full legal notices."; revision2025-01-232026-03-13 { description "This revision adds TLS support. Specifically, this revision adds: - a new feature 'credential-reference' - a new container 'client-credentials' - a new container 'server-credentials' - a new leaf 'domain-name' - a new leaf 'sni-enabled' - TLS as a new security choice - a new leaf 'discontinuity-time' under 'statistics' - a new leaf 'cert-errors' under 'statistics' - a new leaf 'rpk-errors' under 'statistics' Also, this revision: - updates the referenceoffor 'tacacs-plus' identity to also cite RFCSSSS9887 - fixes amust'must' statement under 'tacacs-plus' by adding a missing prefix - requires that theserverslist of servers must be unique per address/port number. - updates the description of the 'name' under 'server' list to better reflect the intended use and clarifies the difference with the new domain-name - updates the description of the 'address' to be consistent with the type - removes the default statement for the 'port' under 'server' list because a distinct default port number is used for TACACS+TLS - updates the 'port' leaf under 'server' list to enumerate the various TACACS+ default port numbers -addedadds a constraint on the VRF with 'source-interface' is also provided - updates the description of timeout to remove redundant text with the default statement"; reference "RFCXXXX:9950: A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)"; } revision 2021-08-05 { description "Initial revision."; reference "RFC 9105: A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)"; } feature credential-reference { description "Indicates whether service credentials references are supported."; } identity tacacs-plus { base sys:authentication-method; description "Indicates AAA operation using TACACS+."; reference "RFCSSSS:9887: Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3 RFC 8907: The TACACS+ Protocol"; } 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 "The type can be set to authentication, authorization, accounting, or any combination of the three types."; } typedef client-credentials-ref { type leafref { path "/sys:system/sys-tcs-plus:tacacs-plus" + "/sys-tcs-plus:client-credentials/sys-tcs-plus:id"; } description "Defines a type to reference client credentials."; } typedef server-credentials-ref { type leafref { path "/sys:system/sys-tcs-plus:tacacs-plus" + "/sys-tcs-plus:server-credentials/sys-tcs-plus:id"; } description "Defines a type to reference server credentials."; } grouping statistics { description "Grouping for TACACS+ statistics attributes, including TLS specifics."; container statistics { config false; description "A collection of server-related statistics objects."; leaf discontinuity-time { type yang:date-and-time; description "The timeonof the most recent occasion at which the TACACS+ client suffered a discontinuity. Examples of discontinuity can be a configuration action to reset all counters, re-initialization of the system, or any other events that prevent reliable contiguous tracking of counters."; } 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 Single Connection Mode was enabled, a single TCP connection may contain multiple TACACS+ sessions."; } leaf cert-errors { type yang:counter64; description "Number of connection failures due to certificate issues."; } leaf rpk-errors { if-feature "tlsc:server-auth-raw-public-key"; type yang:counter64; description "Number of RPK-related connection failures."; } } } grouping certificate { description "Specifies a certificate that can be used for client identity."; uses "ks:inline-or-keystore-end-entity-cert-with-key-" + "grouping" { refine "inline-or-keystore/inline/inline-definition" { must 'not(public-key-format) or derived-from-or-self' + '(public-key-format, "ct:subject-public-key-' + 'info-format")'; } refine "inline-or-keystore/central-keystore/" + "central-keystore-reference/asymmetric-key" { must 'not(deref(.)/../ks:public-key-format) or ' + 'derived-from-or-self(deref(.)/../ks:public-' + 'key-format, "ct:subject-public-key-info-' + 'format")'; } } } grouping raw-private-key { description "Specifies raw private key (RPK) that can be used for client identity."; uses ks:inline-or-keystore-asymmetric-key-grouping { refine "inline-or-keystore/inline/inline-definition" { must 'not(public-key-format) or derived-from-or-self' + '(public-key-format, "ct:subject-public-key-' + 'info-format")'; } refine "inline-or-keystore/central-keystore/" + "central-keystore-reference" { must 'not(deref(.)/../ks:public-key-format) or ' + 'derived-from-or-self(deref(.)/../ks:public-' + 'key-format, "ct:subject-public-key-info-format")'; } } } grouping tls13-epsk { description "An External Pre-Shared Key (EPSK) is established or provisionedout-of-band,out of band, i.e., not from a TLS connection. An EPSK is a tuple of (Base Key, External Identity, Hash). When Pre-Shared Keys (PSKs) are provisioned out of band, the PSK identity and the Key Derivation Function (KDF) hash algorithm to be used with the PSK must also be provisioned."; reference "RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, Section 4.2.11 RFC 9257: Guidance for External Pre-Shared Key (PSK) Usage in TLS, Section 6 RFC 9258: Importing External Pre-Shared Keys (PSKs) for TLS 1.3, Section 5.1"; uses ks:inline-or-keystore-symmetric-key-grouping; leaf external-identity { type string; mandatory true; description "A sequence of bytes used to identify an EPSK. A label for apre-shared keyPSK established externally."; reference "RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, Section 4.2.11 RFC 9257: Guidance for External Pre-Shared Key (PSK) Usage in TLS, Section 4.1"; } leaf hash { type tlscmn:epsk-supported-hash; default "sha-256"; description "For externally established PSKs, the Hash algorithm must be set when the PSK is established or default to SHA-256 if no such algorithm is defined."; reference "RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, Section 4.2.11"; } leaf context { type string; description "The context used to determine the EPSK, if any exists. For example, context may include information about peer roles or identities to mitigate Selfie-style reflection attacks."; reference "RFC 9258: Importing External Pre-Shared Keys (PSKs) for TLS 1.3, Section 5.1 "; } leaf target-protocol { type uint16; description "Specifies the protocol for which a PSK is imported for use."; reference "RFC 9258: Importing External Pre-Shared Keys (PSKs) for TLS 1.3, Section 3 "; } leaf target-kdf { type uint16; description "The KDF for which a PSK is imported for use."; reference "RFC 9258: Importing External Pre-Shared Keys (PSKs) for TLS 1.3, Section 3"; } } grouping client-identity { description "Identity credentials that a TLS client may present when establishing a connection to a TLS server. Whenconfigured,configured and requested by the TLS server when establishing a TLS session, these credentials are passed in the Certificate message."; reference "RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, Section 4.4.2"; choice auth-type { description "A choice amongst authentication types."; case certificate { container certificate { description "Specifies the client identity using a certificate."; uses certificate; } } case raw-public-key { if-feature "tlsc:client-ident-raw-public-key"; container raw-private-key { description "Specifies the client identity using RPK."; uses raw-private-key; } } case tls13-epsk { if-feature "tlsc:client-ident-tls13-epsk"; container tls13-epsk { description "An EPSK is established or provisionedout-of-band.";out of band."; uses tls13-epsk; } } } } grouping client-identity-with-ref { description "Identity credentials that the TLS client may present when establishing a connection to a TLS server. Whenconfigured,configured and requested by the TLS server when establishing a TLS session, these credentials are passed in the Certificate message."; choice ref-or-explicit { description "A choice between a reference or explicit configuration."; case ref { description "Provides a reference to a client identity."; leaf credentials-reference { if-feature "credential-reference"; type sys-tcs-plus:client-credentials-ref; description "Specifies the client credentials reference."; } } case explicit { description "Explicit configuration of the client identity."; uses client-identity; } } } grouping server-authentication { description "Specifies how a TLS client can authenticate TLS servers. Any combination of credentials is additive and unordered."; container ca-certs { presence "Indicates that Certification Authority (CA) certificates have been configured. This statement is present so the mandatory descendant nodes do not imply that this node must be configured."; description "A set of CA certificates used by the TLS client to authenticate TLS server certificates. A server certificate is authenticated if it has a valid chain of trust to a configured CA certificate."; reference "RFC 9641: A YANG Data Model for a Truststore"; uses ts:inline-or-truststore-certs-grouping; } container ee-certs { presence "Indicates that End Entity (EE) certificates have been configured. This statement is present so the mandatory descendant nodes do not imply that this node must be configured."; description "A set of server certificates (i.e., end entity certificates) used by a TLS client to authenticate certificates presented by TLS servers. A server certificate is authenticated if it is an exact match to a configured server certificate."; reference "RFC 9641: A YANG Data Model for a Truststore"; uses ts:inline-or-truststore-certs-grouping; } container raw-public-keys { if-feature "tlsc:server-auth-raw-public-key"; presence "Indicates that raw public keys have been configured. This statement is present so the mandatory descendant nodes do not imply that this node must be configured."; description "A set of raw public keys used by a TLS client to authenticate raw public keys presented by the TLS server. A raw public key is authenticated if it is an exact match to a configured raw public key."; reference "RFC 9641: A YANG Data Model for a Truststore"; uses ts:inline-or-truststore-public-keys-grouping { refine "inline-or-truststore/inline/inline-definition/" + "public-key" { must 'derived-from-or-self(public-key-format,' + ' "ct:subject-public-key-info-format")'; } refine "inline-or-truststore/central-truststore/" + "central-truststore-reference" { must 'not(deref(.)/../ts:public-key/ts:public-key-' + 'format[not(derived-from-or-self(., "ct:subject-' + 'public-key-info-format"))])'; } } } leaf tls13-epsks { if-feature "tlsc:server-auth-tls13-epsk"; type empty; description "Indicates that a TLS client can authenticate TLS servers using configured EPSKs."; } } grouping server-authentication-with-ref { description "Specifies how a TLS client can authenticate TLS servers."; choice ref-or-explicit { description "A choice between a referenceofor explicit configuration."; case ref { description "Provides a reference to server credentials."; leaf credentials-reference { if-feature "credential-reference"; type sys-tcs-plus:server-credentials-ref; description "Specifies the server credentials reference."; } } case explicit { description "Explicit configuration of credentials of a server."; uses server-authentication; } } } grouping hello-params { description "Configurable parameters for the TLS Hello message."; reference "RFCSSSS:9887: Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3, Section 5.1"; uses tlscmn:hello-params-grouping { refine "tls-versions/min" { must "not(derived-from-or-self(current(), " + "'tlscmn:tls12'))" { error-message "TLS 1.2 is not supported as min TLS version"; } } refine "tls-versions/max" { must "not(derived-from-or-self(current(), " + "'tlscmn:tls12'))" { error-message "TLS 1.2 is not supported as max TLS version"; } } } } grouping tls-client { description "A grouping for configuring a TLS client without any consideration for how an underlying TCP session is established."; container client-identity { presence "Indicates that a TLS-level client identity has been configured. This statement is present so the mandatory descendant do not imply that this node must be configured."; description "Identity credentials that a TLS client may present when establishing a connection to a TLS server."; uses client-identity-with-ref; } container server-authentication { must 'credentials-reference or ca-certs or ee-certs or ' + 'raw-public-keys or tls13-epsks'; description "Specifies how a TLS client can authenticate TLS servers."; uses server-authentication-with-ref; } container hello-params { if-feature "tlscmn:hello-params"; description "Configurable parameters for the TLS Hello message."; uses hello-params; } } grouping tacacs-plus { description "Grouping for TACACS+ attributes."; container tacacs-plus { must "not(derived-from-or-self(../sys:authentication" + "/sys:user-authentication-order, " + "'sys-tcs-plus: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 client-credentials { if-feature "credential-reference"; key "id"; description "Identity credentials that a TLS client may present when establishing a connection to a TLS server. A list of client credentials that can be referenced when configuring server instances."; nacm:default-deny-write; leaf id { type string; description "An identifier that uniquely identifies a client identity within the device configuration."; } uses client-identity; } list server-credentials { if-feature "credential-reference"; key "id"; description "Identity credentials that a TLS client may use to authenticate a TLS server."; nacm:default-deny-write; leaf id { type string; description "An identifier that uniquelyidentifyidentifies server credentials within the device configuration."; } uses server-authentication; } list server { key "name"; unique "address port"; ordered-by user; description "List of TACACS+ servers used by the device."; leaf name { type string; description "A name that is used to uniquely identify a TACACS+ server within the device configuration. This name is not to be confused with the domain-name."; } leaf server-type { type tacacs-plus-server-type; mandatory true; description "Server type: authentication/authorization/accounting and various combinations."; } leaf domain-name { type inet:domain-name; description "Provides a domain name of the TACACS+ server."; reference "RFCSSSS:9887: Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3, Section 3.4.2"; } leaf sni-enabled { type boolean; must '../domain-name' { error-message "A domain name must be provided to make use of Server Name Indication (SNI)."; } description "Enables the use ofSNI,SNI when set to true. Disables the use ofSNI,SNI when set to false."; reference "RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions, Section 3 RFCSSSS:9887: Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3, Section 3.4.2"; } leaf address { type inet:host; mandatory true; description "The IP address or name of the TACACS+ server."; } leaf port { type inet:port-number; mandatory true; description "The port number of the TACACS+ server.DefaultThe default port number for legacy TACACS+ is 49, while it isTBD300 for TACACS+TLS."; } choice security { mandatory true; description "Security mechanism between TACACS+ client and server."; case tls { description "TLS is used to secure TACACS+ exchanges."; reference "RFCSSSS:9887: Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3"; uses tls-client; } case obfuscation { leaf shared-secret { type string { length "1..max"; } 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. The use of obfuscation is deprecated in favor of TLS. This choice is provided in the model to accommodate installed base."; reference "RFC 8907: The TACACS+ Protocol RFCSSSS:9887: Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3"; nacm:default-deny-all; } } } choice source-type { description "The source address type for outbound TACACS+ packets."; case source-ip { leaf source-ip { type inet:ip-address; description "Specifies the 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 outbound TACACS+ packets."; } } } leaf vrf-instance { type leafref { path "/ni:network-instances/ni:network-instance/ni:name"; } must "(not(../source-interface)) or " + "(current() = /if:interfaces/if:interface" + "[if:name = current()/../source-interface]" + "/ni:bind-ni-name)" { error-message "VRF instance must match the network instance of the source interface."; } description "Specifies the VPN Routing and Forwarding (VRF) instance to use to communicate with the TACACS+ server. If 'source-interface' is configured, this value MUST match the network instance bound to the source interface (via bind-ni-name)."; 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."; reference "RFC 8907: The TACACS+ Protocol, Section 4.3"; } leaf timeout { type uint16 { range "1..max"; } units "seconds"; default "5"; description "The number of seconds that 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 data nodes."; uses tacacs-plus; } }<CODE ENDS>]]></sourcecode> </section> <section anchor="operational-considerations"> <name>Operational Considerations</name> <t>The same operational considerations discussed in <xref section="6" sectionFormat="of"target="I-D.ietf-opsawg-tacacs-tls13"/>target="RFC9887"/> apply for this document.</t> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <!-- [rfced] Security Considerations a) This document informatively references [I-D.ietf-netmod-rfc8407bis], which is currently in AUTH48 as RFC-to-be 9907. It seems that it will be published soon, so we updated the reference in this document to [RFC9907]. We also made a few small updates to the Security Considerations section of this document to align with the template as it currently appears in Section 3.7.1 of RFC-to-be 9907. b) We added the following sentences before the last paragraph in the Security Considerations section per Section 3.7.1 of RFC-to-be 9907. Please confirm this is correct. Perhaps: There are no particularly sensitive readable data nodes. There are no particularly sensitive RPC or action operations. --> <t>This section is modeled after the template described in <xrefsection="3.7"section="3.7.1" sectionFormat="of"target="I-D.ietf-netmod-rfc8407bis"/>.</t>target="RFC9907"/>.</t> <t>The "ietf-ac-common" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such asNETCONFthe Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These YANG-based management protocols (1) have to use a secure transport layer (e.g.,SSHSecure Shell (SSH) <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, and QUIC <xref target="RFC9000"/>) and (2) have to use mutual authentication.</t> <t>The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.</t> <t>There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities:</t> <dl> <dt>'server':</dt> <dd> <t>This list contains the data nodes used to control the TACACS+ servers used by the device. Unauthorized access to this list could enable an attacker to assume complete control over the device by pointing to a compromised TACACS+ server, or to modify the counters to hide attacks against the device.</t> </dd> <dt>'shared-secret':</dt> <dd> <t>This leaf controls the key known to both the TACACS+ client and server. Unauthorized access to this leaf could make the device vulnerable to attacks; therefore, it has been restricted using the "default-deny-all" access control defined in <xref target="RFC8341"/>. When setting, it is highly recommended that the leaf 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.</t> </dd> <dt>'client-identity' and 'server-authentication':</dt> <dd> <t>Any modification to a key or reference to a key may dramatically alter the implemented security policy. For this reason, the NACM extension "default-deny-write" has been set.</t> </dd> </dl> <t>There are no particularly sensitive readable data nodes.</t> <t>There are no particularly sensitive RPC or action operations.</t> <t>This YANG module uses groupings from other YANG modules that define nodes that may be considered sensitive or vulnerable in network environments. Refer to <xref section="5.3" sectionFormat="of" target="RFC9642"/> and <xref section="5.3" sectionFormat="of" target="RFC9645"/> for information as to which nodes may be considered sensitive or vulnerable in network environments.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>IANAis requested to updatehas registered the following URI in the "ns"subregistryregistry within the "IETF XML Registry" <xref target="RFC3688"/>:</t><artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-system-tacacs-plus Registrant Contact: The IESG. XML: N/A;<dl spacing="compact" newline="false"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-system-tacacs-plus</dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace. ]]></artwork>namespace.</dd> </dl> <t>IANAis requested to registerhas registered the following YANG module in the "YANG Module Names" registry <xref target="RFC6020"/> within the "YANG Parameters" registry group:</t><artwork><![CDATA[ Name: ietf-system-tacacs-plus Namespace: urn:ietf:params:xml:ns:yang:ietf-system-tacacs-plus Prefix: sys-tcs-plus Maintained<dl spacing="compact" newline="false"> <dt>Name:</dt><dd>ietf-system-tacacs-plus</dd> <dt>Maintained byIANA? N Reference: RFC XXXX ]]></artwork>IANA?</dt><dd>N</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-system-tacacs-plus</dd> <dt>Prefix:</dt><dd>sys-tcs-plus</dd> <dt>Reference:</dt><dd>RFC 9950</dd> </dl> </section> </middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC7317"> <front> <title>A YANG Data Model for System Management</title> <author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <date month="August" year="2014"/> <abstract> <t>This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management.</t> </abstract> </front> <seriesInfo name="RFC" value="7317"/> <seriesInfo name="DOI" value="10.17487/RFC7317"/> </reference> <reference anchor="I-D.ietf-opsawg-tacacs-tls13"> <front> <title>Terminal Access Controller Access-Control System Plus over TLS 1.3 (TACACS+ over TLS)</title> <author fullname="Thorsten Dahm" initials="T." surname="Dahm"> </author> <author fullname="John Heasley" initials="J." surname="Heasley"> <organization>NTT</organization> </author> <author fullname="dcmgash@cisco.com" initials="" surname="dcmgash@cisco.com"> <organization>Cisco Systems, Inc.</organization> </author> <author fullname="Andrej Ota" initials="A." surname="Ota"> <organization>Google Inc.</organization> </author> <date day="21" month="June" year="2025"/> <abstract> <t> The Terminal Access Controller Access-Control System Plus (TACACS+) protocol provides device administration for routers, network access servers, and other networked computing devices via one or more centralized TACACS+ servers. This document adds Transport Layer Security (TLS 1.3) support to TACACS+ and obsoletes former inferior security mechanisms. This document updates RFC 8907. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-tacacs-tls13-23"/> </reference> <reference anchor="RFC8342"> <front> <title>Network Management Datastore Architecture (NMDA)</title> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/> <author fullname="P. Shafer" initials="P." surname="Shafer"/> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <author fullname="R. Wilton" initials="R." surname="Wilton"/> <date month="March" year="2018"/> <abstract> <t>Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.</t> </abstract> </front> <seriesInfo name="RFC" value="8342"/> <seriesInfo name="DOI" value="10.17487/RFC8342"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC7950"> <front> <title>The YANG 1.1 Data Modeling Language</title> <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/> <date month="August" year="2016"/> <abstract> <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t> </abstract> </front> <seriesInfo name="RFC" value="7950"/> <seriesInfo name="DOI" value="10.17487/RFC7950"/> </reference> <reference anchor="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="RFC6066"> <front> <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/> <date month="January" year="2011"/> <abstract> <t>This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6066"/> <seriesInfo name="DOI" value="10.17487/RFC6066"/> </reference> <reference anchor="RFC6991"> <front> <title>Common YANG Data Types</title> <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/> <date month="July" year="2013"/> <abstract> <t>This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.</t> </abstract> </front> <seriesInfo name="RFC" value="6991"/> <seriesInfo name="DOI" value="10.17487/RFC6991"/> </reference> <reference anchor="RFC8341"> <front> <title>Network Configuration Access Control Model</title> <author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <date month="March" year="2018"/> <abstract> <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t> <t>This document obsoletes RFC 6536.</t> </abstract> </front> <seriesInfo name="STD" value="91"/> <seriesInfo name="RFC" value="8341"/> <seriesInfo name="DOI" value="10.17487/RFC8341"/> </reference> <reference anchor="RFC8343"> <front> <title>A YANG Data Model for Interface Management</title> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <date month="March" year="2018"/> <abstract> <t>This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).</t> <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t> <t>This document obsoletes RFC 7223.</t> </abstract> </front> <seriesInfo name="RFC" value="8343"/> <seriesInfo name="DOI" value="10.17487/RFC8343"/> </reference> <reference anchor="RFC8529"> <front> <title>YANG Data Model for Network Instances</title> <author fullname="L. Berger" initials="L." surname="Berger"/> <author fullname="C. Hopps" initials="C." surname="Hopps"/> <author fullname="A. Lindem" initials="A." surname="Lindem"/> <author fullname="D. Bogdanovic" initials="D." surname="Bogdanovic"/> <author fullname="X. Liu" initials="X." surname="Liu"/> <date month="March" year="2019"/> <abstract> <t>This document defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs).</t> <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t> </abstract> </front> <seriesInfo name="RFC" value="8529"/> <seriesInfo name="DOI" value="10.17487/RFC8529"/> </reference> <reference anchor="RFC9640"> <front> <title>YANG Data Types and Groupings for Cryptography</title> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <date month="October" year="2024"/> <abstract> <t>This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications.</t> </abstract> </front> <seriesInfo name="RFC" value="9640"/> <seriesInfo name="DOI" value="10.17487/RFC9640"/> </reference> <reference anchor="RFC9641"> <front> <title>A YANG Data Model for a Truststore</title> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <date month="October" year="2024"/> <abstract> <t>This document presents a YANG module for configuring bags of certificates and bags of public keys that can be referenced by other data models for trust. Notifications are sent when certificates are about to expire.</t> </abstract> </front> <seriesInfo name="RFC" value="9641"/> <seriesInfo name="DOI" value="10.17487/RFC9641"/> </reference> <reference anchor="RFC9642"> <front> <title>A YANG Data Model for a Keystore</title> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <date month="October" year="2024"/> <abstract> <t>This document presents a YANG module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted or hidden. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire.</t> </abstract> </front> <seriesInfo name="RFC" value="9642"/> <seriesInfo name="DOI" value="10.17487/RFC9642"/> </reference> <reference anchor="RFC9645"> <front> <title>YANG Groupings for TLS Clients and TLS Servers</title> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <date month="October" year="2024"/> <abstract> <t>This document presents four YANG 1.1 modules -- three IETF modules and one supporting IANA module.</t> <t>The three IETF modules are "ietf-tls-common", "ietf-tls-client", and "ietf-tls-server". The "ietf-tls-client" and "ietf-tls-server" modules are the primary productions of this work, supporting the configuration and monitoring of TLS clients and servers.</t> <t>The IANA module is "iana-tls-cipher-suite-algs". This module defines YANG enumerations that provide support for an IANA-maintained algorithm registry.</t> </abstract> </front> <seriesInfo name="RFC" value="9645"/> <seriesInfo name="DOI" value="10.17487/RFC9645"/> </reference> <reference anchor="RFC6520"> <front> <title>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension</title> <author fullname="R. Seggelmann" initials="R." surname="Seggelmann"/> <author fullname="M. Tuexen" initials="M." surname="Tuexen"/> <author fullname="M. Williams" initials="M." surname="Williams"/> <date month="February" year="2012"/> <abstract> <t>This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.</t> <t>The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6520"/> <seriesInfo name="DOI" value="10.17487/RFC6520"/> </reference> <reference anchor="RFC9257"> <front> <title>Guidance for External Pre-Shared Key (PSK) Usage in TLS</title> <author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="J. Hoyland" initials="J." surname="Hoyland"/> <author fullname="M. Sethi" initials="M." surname="Sethi"/> <author fullname="C. A. Wood" initials="C. A." surname="Wood"/> <date month="July" year="2022"/> <abstract> <t>This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used.</t> </abstract> </front> <seriesInfo name="RFC" value="9257"/> <seriesInfo name="DOI" value="10.17487/RFC9257"/> </reference> <reference anchor="RFC9258"> <front> <title>Importing External Pre-Shared Keys (PSKs) for TLS 1.3</title> <author fullname="D. Benjamin" initials="D." surname="Benjamin"/> <author fullname="C. A. Wood" initials="C. A." surname="Wood"/> <date month="July" year="2022"/> <abstract> <t>This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3.</t> </abstract> </front> <seriesInfo name="RFC" value="9258"/> <seriesInfo name="DOI" value="10.17487/RFC9258"/> </reference> <reference anchor="RFC3688"> <front> <title>The IETF XML Registry</title> <author fullname="M. Mealling" initials="M." surname="Mealling"/> <date month="January" year="2004"/> <abstract> <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t> </abstract> </front> <seriesInfo name="BCP" value="81"/> <seriesInfo name="RFC" value="3688"/> <seriesInfo name="DOI" value="10.17487/RFC3688"/> </reference> <reference anchor="RFC6020"> <front> <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title> <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/> <date month="October" year="2010"/> <abstract> <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6020"/> <seriesInfo name="DOI" value="10.17487/RFC6020"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7317.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9887.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8529.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9640.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9641.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9642.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9645.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6520.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9257.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9258.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC9105"> <front> <title>A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)</title> <author fullname="B. Wu" initials="B." role="editor" surname="Wu"/> <author fullname="G. Zheng" initials="G." surname="Zheng"/> <author fullname="M. Wang" initials="M." role="editor" surname="Wang"/> <date month="August" year="2021"/> <abstract> <t>This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Though being a standard module, this module does not endorse the security mechanisms of the TACACS+ protocol (RFC 8907), and TACACS+ be used within a secure deployment.</t> <t>The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.</t> </abstract> </front> <seriesInfo name="RFC" value="9105"/> <seriesInfo name="DOI" value="10.17487/RFC9105"/> </reference> <reference anchor="RFC2865"> <front> <title>Remote Authentication Dial<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9105.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8907.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <!-- [I-D.ietf-netmod-rfc8407bis] draft-ietf-netmod-rfc8407bis-28 InUser Service (RADIUS)</title> <author fullname="C. Rigney" initials="C." surname="Rigney"/> <author fullname="S. Willens" initials="S." surname="Willens"/> <author fullname="A. Rubens" initials="A." surname="Rubens"/> <author fullname="W. Simpson" initials="W." surname="Simpson"/> <date month="June" year="2000"/> <abstract> <t>This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2865"/> <seriesInfo name="DOI" value="10.17487/RFC2865"/> </reference> <reference anchor="RFC8907"> <front> <title>The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol</title> <author fullname="T. Dahm" initials="T." surname="Dahm"/> <author fullname="A. Ota" initials="A." surname="Ota"/> <author fullname="D.C. Medway Gash" initials="D.C." surname="Medway Gash"/> <author fullname="D. Carrel" initials="D." surname="Carrel"/> <author fullname="L. Grant" initials="L." surname="Grant"/> <date month="September" year="2020"/> <abstract> <t>This document describes the Terminal Access Controller Access-Control System Plus (TACACS+) protocol, which is widely deployed today to provide Device Administration for routers, network access servers, and other networked computing devices via one or more centralized servers.</t> </abstract> </front> <seriesInfo name="RFC" value="8907"/> <seriesInfo name="DOI" value="10.17487/RFC8907"/> </reference> <reference anchor="RFC8340"> <front> <title>YANG Tree Diagrams</title> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/> <date month="March" year="2018"/> <abstract> <t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolutionAUTH48 as ofthe YANG language.</t> </abstract> </front> <seriesInfo name="BCP" value="215"/> <seriesInfo name="RFC" value="8340"/> <seriesInfo name="DOI" value="10.17487/RFC8340"/> </reference>3/9/2026 at RFC 9907 --> <referenceanchor="I-D.ietf-netmod-rfc8407bis">anchor="RFC9907" target="https://www.rfc-editor.org/info/rfc9907"> <front> <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title> <authorfullname="Andy Bierman"initials="A."surname="Bierman"> <organization>YumaWorks</organization>surname="Bierman" fullname="Andy Bierman"> </author> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair"> <organization>Orange</organization>role="editor"> </author> <authorfullname="Qin Wu"initials="Q."surname="Wu"> <organization>Huawei</organization>surname="Wu" fullname="Qin Wu"> </author> <dateday="5" month="June" year="2025"/> <abstract> <t> This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF Protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-28"/> </reference> <reference anchor="RFC6241"> <front> <title>Network Configuration Protocol (NETCONF)</title> <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/> <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/> <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/> <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/> <date month="June" year="2011"/> <abstract> <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6241"/> <seriesInfo name="DOI" value="10.17487/RFC6241"/> </reference> <reference anchor="RFC8040"> <front> <title>RESTCONF Protocol</title> <author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <date month="January" year="2017"/> <abstract> <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t> </abstract> </front> <seriesInfo name="RFC" value="8040"/> <seriesInfo name="DOI" value="10.17487/RFC8040"/> </reference> <reference anchor="RFC4252"> <front> <title>The Secure Shell (SSH) Authentication Protocol</title> <author fullname="T. Ylonen" initials="T." surname="Ylonen"/> <author fullname="C. Lonvick" initials="C." role="editor" surname="Lonvick"/> <date month="January" year="2006"/> <abstract> <t>The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4252"/> <seriesInfo name="DOI" value="10.17487/RFC4252"/> </reference> <reference anchor="RFC9000"> <front> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/> <date month="May" year="2021"/> <abstract> <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t> </abstract>month="March" year="2026" /> </front> <seriesInfo name="RFC"value="9000"/>value="9907"/> <seriesInfo name="DOI"value="10.17487/RFC9000"/>value="10.17487/RFC9907"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> </references> </references><?line 1237?><section anchor="example-tacacs-authentication-configuration-with-shared-secret"> <name>Example TACACS+ Authentication Configuration with Shared Secret</name> <t><xref target="ex9105"/> shows an example where a TACACS+ authentication server instance is configured using a shared secret for authentication. This mode is not recommended per <xreftarget="I-D.ietf-opsawg-tacacs-tls13"/>.</t>target="RFC9887"/>.</t> <figure anchor="ex9105"> <name>Example with Shared Secret</name> <sourcecode type="json"><![CDATA[ { "ietf-system:system": { "authentication": { "user-authentication-order": [ "ietf-system-tacacs-plus:tacacs-plus", "ietf-system:local-users" ] }, "ietf-system-tacacs-plus: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 } ] } } } ]]></sourcecode> </figure> <t><xref target="ex9105-vrf"/> provides an example to associate a TACACS+ server with a VRF.</t> <figure anchor="ex9105-vrf"> <name>Example with VRF</name> <sourcecode type="json"><![CDATA[ { "ietf-network-instance:network-instances": { "network-instance": [ { "name": "MANAGEMENT_VRF", "description": "Management VRF for TACACS+ traffic isolation" } ] }, "ietf-system:system": { "authentication": { "user-authentication-order": [ "ietf-system-tacacs-plus:tacacs-plus", "ietf-system:local-users" ] }, "ietf-system-tacacs-plus:tacacs-plus": { "server": [ { "name": "tac_plus1", "server-type": "authentication", "address": "192.0.2.2", "shared-secret": "QaEfThUkO198010075460923+h3TbE8n", "source-ip": "192.0.2.12", "vrf-instance": "MANAGEMENT_VRF", "timeout": 10 } ] } } } ]]></sourcecode> </figure> </section> <!-- [rfced] The figures in Appendix B and Appendix C include a note about using line wrapping per RFC 8792, but this document does not include a reference entry for RFC 8792. May we add something like the following to Section 2 ("Conventions and Definitions") and a corresponding informative reference entry? Perhaps A (after key words paragraph in Section 2): Some examples in this document contain long lines that are wrapped as described in [RFC8792]. or Perhaps B (after Section 2.1): 2.2. Line Wrapping Some examples in this document contain long lines that are wrapped as described in [RFC8792]. --> <section anchor="tacacstls-examples"> <name>TACACS+TLS Examples</name> <t>This section provides examples to illustrate the configuration of TACACS+TLS clients.</t> <t>These examples follow the convention used in <xref section="1.5" sectionFormat="of" target="RFC9645"/> for binary data that has been base64 encoded.</t> <section anchor="example-tacacs-authentication-configuration-with-explicit-certificate-definitions"> <name>Example TACACS+ Authentication Configuration with Explicit Certificate Definitions</name> <t><xref target="exin"/> shows a configuration example with 'inline-definition' for the client identity and server authentication.</t> <figure anchor="exin"> <name>Example with TACACS+TLS with Inline Certificate Definitions</name> <sourcecode type="json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-system:system": { "authentication": { "user-authentication-order": [ "ietf-system-tacacs-plus:tacacs-plus", "ietf-system:local-users" ] }, "ietf-system-tacacs-plus:tacacs-plus": { "server": [ { "name": "instance-1", "server-type": "authentication", "domain-name": "tacacs.example.com", "sni-enabled": true, "address": "2001:db8::1", "port": 1234, "client-identity": { "certificate": { "inline-definition": { "public-key-format": "ietf-crypto-types:subject-\ public-key-info-format", "public-key": "BASE64VALUE=", "private-key-format": "ietf-crypto-types:rsa-private\ -key-format", "cleartext-private-key": "BASE64VALUE=", "cert-data": "BASE64VALUE=" } } }, "server-authentication": { "ca-certs": { "inline-definition": { "certificate": [ { "name": "CA-Certificate-1", "cert-data": "BASE64VALUE=" } ] } } }, "hello-params": { "tls-versions": { "min": "ietf-tls-common:tls13", "max": "ietf-tls-common:tls13" }, "cipher-suites": { "cipher-suite": [ "TLS_AES_128_GCM_SHA256" ] } }, "single-connection": false, "timeout": 10 } ] } } } ]]></sourcecode> </figure> </section> <section anchor="example-tacacs-authentication-configuration-with-certificate-references"> <name>Example TACACS+ Authentication Configuration with Certificate References</name> <t><xref target="ex-ref"/> shows a configuration example with credential references for multiple serviceinstances: fourinstances. Four server instances areconfigured withconfigured, all using the same credentials. These instances form a redundancy group for both IPv4 and IPv6.</t> <figure anchor="ex-ref"> <name>Example with TACACS+TLS with References</name> <sourcecode type="json"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-system:system": { "ietf-system-tacacs-plus:tacacs-plus": { "client-credentials": [ { "id": "client-cred-1", "certificate": { "inline-definition": { "public-key-format": "ietf-crypto-types:subject-public\ -key-info-format", "public-key": "BASE64VALUE=", "private-key-format": "ietf-crypto-types:rsa-private-\ key-format", "cleartext-private-key": "BASE64VALUE=", "cert-data": "BASE64VALUE=" } } } ], "server-credentials": [ { "id": "server-cred-1", "ca-certs": { "inline-definition": { "certificate": [ { "name": "CA-Certificate-1", "cert-data": "BASE64VALUE=" } ] } } } ], "server": [ { "name": "primary-v6", "server-type": "authentication", "domain-name": "tacacs.example.com", "sni-enabled": true, "address": "2001:db8::1", "port": 1234, "client-identity": { "credentials-reference": "client-cred-1" }, "server-authentication": { "credentials-reference": "server-cred-1" } }, { "name": "backup-v6", "server-type": "authentication", "domain-name": "tacacs.example.com", "sni-enabled": true, "address": "2001:db8::2", "port": 1234, "client-identity": { "credentials-reference": "client-cred-1" }, "server-authentication": { "credentials-reference": "server-cred-1" } }, { "name": "primary-v4", "server-type": "authentication", "domain-name": "tacacs.example.com", "sni-enabled": true, "address": "192.0.2.1", "port": 49, "client-identity": { "credentials-reference": "client-cred-1" }, "server-authentication": { "credentials-reference": "server-cred-1" } }, { "name": "backup-v4", "server-type": "authentication", "domain-name": "tacacs.example.com", "sni-enabled": true, "address": "192.0.2.2", "port": 49, "client-identity": { "credentials-reference": "client-cred-1" }, "server-authentication": { "credentials-reference": "server-cred-1" } } ] } } } ]]></sourcecode> </figure> </section> </section> <section anchor="sec-full"> <name>Full Tree</name> <t>The full tree structure is shown below:</t><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ =============== NOTE: '\' line wrapping per RFC 8792 ================ module: ietf-system-tacacs-plus augment /sys:system: +--rw tacacs-plus +--rw client-credentials* [id] {credential-reference}? | +--rw id string | +--rw (auth-type)? | +--:(certificate) | | +--rw certificate | | +--rw (inline-or-keystore) | | +--:(inline) {inline-definitions-supported}? | | | +--rw inline-definition | | | +--rw public-key-format? | | | | identityref | | | +--rw public-key? | | | | binary | | | +--rw private-key-format? | | | | identityref | | | +--rw (private-key-type) | | | | +--:(cleartext-private-key) | | | | | {cleartext-private-keys}? | | | | | +--rw cleartext-private-key? | | | | | binary | | | | +--:(hidden-private-key) | | | | | {hidden-private-keys}? | | | | | +--rw hidden-private-key? | | | | | empty | | | | +--:(encrypted-private-key) | | | | {encrypted-private-keys}? | | | | +--rw encrypted-private-key | | | | +--rw encrypted-by | | | | +--rw encrypted-value-format | | | | | identityref | | | | +--rw encrypted-value | | | | binary | | | +--rw cert-data? | | | | end-entity-cert-cms | | | +---n certificate-expiration | | | | {certificate-expiration-\ notification}? | | | | +-- expiration-date | | | | yang:date-and-time | | | +---x generate-csr {csr-generation}? | | | +---w input | | | | +---w csr-format identityref | | | | +---w csr-info csr-info | | | +--ro output | | | +--ro (csr-type) | | | +--:(p10-csr) | | | +--ro p10-csr? p10-csr | | +--:(central-keystore) | | {central-keystore-supported,\ asymmetric-keys}? | | +--rw central-keystore-reference | | +--rw asymmetric-key? | | | ks:central-asymmetric-key-ref | | | {central-keystore-supported,\ asymmetric-keys}? | | +--rw certificate? leafref | +--:(raw-public-key) {tlsc:client-ident-raw-public-key}? | | +--rw raw-private-key | | +--rw (inline-or-keystore) | | +--:(inline) {inline-definitions-supported}? | | | +--rw inline-definition | | | +--rw public-key-format? | | | | identityref | | | +--rw public-key? | | | | binary | | | +--rw private-key-format? | | | | identityref | | | +--rw (private-key-type) | | | +--:(cleartext-private-key) | | | | {cleartext-private-keys}? | | | | +--rw cleartext-private-key? | | | | binary | | | +--:(hidden-private-key) | | | | {hidden-private-keys}? | | | | +--rw hidden-private-key? | | | | empty | | | +--:(encrypted-private-key) | | | {encrypted-private-keys}? | | | +--rw encrypted-private-key | | | +--rw encrypted-by | | | +--rw encrypted-value-format | | | | identityref | | | +--rw encrypted-value | | | binary | | +--:(central-keystore) | | {central-keystore-supported,\ asymmetric-keys}? | | +--rw central-keystore-reference? | | ks:central-asymmetric-key-ref | +--:(tls13-epsk) {tlsc:client-ident-tls13-epsk}? | +--rw tls13-epsk | +--rw (inline-or-keystore) | | +--:(inline) {inline-definitions-supported}? | | | +--rw inline-definition | | | +--rw key-format? | | | | identityref | | | +--rw (key-type) | | | +--:(cleartext-symmetric-key) | | | | +--rw cleartext-symmetric-key? | | | | binary | | | | {cleartext-symmetric-keys}? | | | +--:(hidden-symmetric-key) | | | | {hidden-symmetric-keys}? | | | | +--rw hidden-symmetric-key? | | | | empty | | | +--:(encrypted-symmetric-key) | | | {encrypted-symmetric-keys}? | | | +--rw encrypted-symmetric-key | | | +--rw encrypted-by | | | +--rw encrypted-value-format | | | | identityref | | | +--rw encrypted-value | | | binary | | +--:(central-keystore) | | {central-keystore-supported,symmetric\ -keys}? | | +--rw central-keystore-reference? | | ks:central-symmetric-key-ref | +--rw external-identity string | +--rw hash? | | tlscmn:epsk-supported-hash | +--rw context? string | +--rw target-protocol? uint16 | +--rw target-kdf? uint16 +--rw server-credentials* [id] {credential-reference}? | +--rw id string | +--rw ca-certs! | | +--rw (inline-or-truststore) | | +--:(inline) {inline-definitions-supported}? | | | +--rw inline-definition | | | +--rw certificate* [name] | | | +--rw name string | | | +--rw cert-data | | | | trust-anchor-cert-cms | | | +---n certificate-expiration | | | {certificate-expiration-\ notification}? | | | +-- expiration-date yang:date-and-time | | +--:(central-truststore) | | {central-truststore-supported,certificates}? | | +--rw central-truststore-reference? | | ts:central-certificate-bag-ref | +--rw ee-certs! | | +--rw (inline-or-truststore) | | +--:(inline) {inline-definitions-supported}? | | | +--rw inline-definition | | | +--rw certificate* [name] | | | +--rw name string | | | +--rw cert-data | | | | trust-anchor-cert-cms | | | +---n certificate-expiration | | | {certificate-expiration-\ notification}? | | | +-- expiration-date yang:date-and-time | | +--:(central-truststore) | | {central-truststore-supported,certificates}? | | +--rw central-truststore-reference? | | ts:central-certificate-bag-ref | +--rw raw-public-keys! {tlsc:server-auth-raw-public-key}? | | +--rw (inline-or-truststore) | | +--:(inline) {inline-definitions-supported}? | | | +--rw inline-definition | | | +--rw public-key* [name] | | | +--rw name string | | | +--rw public-key-format identityref | | | +--rw public-key binary | | +--:(central-truststore) | | {central-truststore-supported,public-keys}? | | +--rw central-truststore-reference? | | ts:central-public-key-bag-ref | +--rw tls13-epsks? empty | {tlsc:server-auth-tls13-epsk}? +--rw server* [name] +--rw name string +--rw server-type | tacacs-plus-server-type +--rw domain-name? inet:domain-name +--rw sni-enabled? boolean +--rw address inet:host +--rw port inet:port-number +--rw (security) | +--:(tls) | | +--rw client-identity! | | | +--rw (ref-or-explicit)? | | | +--:(ref) | | | | +--rw credentials-reference? | | | | sys-tcs-plus:client-credentials-ref | | | | {credential-reference}? | | | +--:(explicit) | | | +--rw (auth-type)? | | | +--:(certificate) | | | | +--rw certificate | | | | +--rw (inline-or-keystore) | | | | +--:(inline) | | | | | {inline-definitions-\ supported}? | | | | | +--rw inline-definition | | | | | +--rw public-key-format? | | | | | | identityref | | | | | +--rw public-key? | | | | | | binary | | | | | +--rw private-key-format? | | | | | | identityref | | | | | +--rw (private-key-type) | | | | | | +--:(cleartext-private\ -key) | | | | | | | {cleartext-\ private-keys}? | | | | | | | +--rw cleartext-\ private-key? | | | | | | | binary | | | | | | +--:(hidden-private-\ key) | | | | | | | {hidden-\ private-keys}? | | | | | | | +--rw hidden-\ private-key? | | | | | | | empty | | | | | | +--:(encrypted-private\ -key) | | | | | | {encrypted-\ private-keys}? | | | | | | +--rw encrypted-\ private-key | | | | | | +--rw encrypted-\ by | | | | | | +--rw encrypted-\ value-format | | | | | | | \ identityref | | | | | | +--rw encrypted-\ value | | | | | | binary | | | | | +--rw cert-data? | | | | | | end-entity-cert-\ cms | | | | | +---n certificate-\ expiration | | | | | | {certificate-\ expiration-notification}? | | | | | | +-- expiration-date | | | | | | yang:date-and-\ time | | | | | +---x generate-csr | | | | | {csr-generation}? | | | | | +---w input | | | | | | +---w csr-format | | | | | | | identityref | | | | | | +---w csr-info | | | | | | csr-info | | | | | +--ro output | | | | | +--ro (csr-type) | | | | | +--:(p10-csr) | | | | | +--ro p10-csr? | | | | | p10-\ csr | | | | +--:(central-keystore) | | | | {central-keystore-\ supported,asymmetric-keys}? | | | | +--rw central-keystore-\ reference | | | | +--rw asymmetric-key? | | | | | ks:central-\ asymmetric-key-ref | | | | | {central-keystore\ -supported,asymmetric-keys}? | | | | +--rw certificate? | | | | leafref | | | +--:(raw-public-key) | | | | {tlsc:client-ident-raw-public-\ key}? | | | | +--rw raw-private-key | | | | +--rw (inline-or-keystore) | | | | +--:(inline) | | | | | {inline-definitions-\ supported}? | | | | | +--rw inline-definition | | | | | +--rw public-key-format? | | | | | | identityref | | | | | +--rw public-key? | | | | | | binary | | | | | +--rw private-key-format? | | | | | | identityref | | | | | +--rw (private-key-type) | | | | | +--:(cleartext-private\ -key) | | | | | | {cleartext-\ private-keys}? | | | | | | +--rw cleartext-\ private-key? | | | | | | binary | | | | | +--:(hidden-private-\ key) | | | | | | {hidden-\ private-keys}? | | | | | | +--rw hidden-\ private-key? | | | | | | empty | | | | | +--:(encrypted-private\ -key) | | | | | {encrypted-\ private-keys}? | | | | | +--rw encrypted-\ private-key | | | | | +--rw encrypted-\ by | | | | | +--rw encrypted-\ value-format | | | | | | \ identityref | | | | | +--rw encrypted-\ value | | | | | binary | | | | +--:(central-keystore) | | | | {central-keystore-\ supported,asymmetric-keys}? | | | | +--rw central-keystore-\ reference? | | | | ks:central-\ asymmetric-key-ref | | | +--:(tls13-epsk) | | | {tlsc:client-ident-tls13-epsk}? | | | +--rw tls13-epsk | | | +--rw (inline-or-keystore) | | | | +--:(inline) | | | | | {inline-definitions-\ supported}? | | | | | +--rw inline-definition | | | | | +--rw key-format? | | | | | | identityref | | | | | +--rw (key-type) | | | | | +--:(cleartext-\ symmetric-key) | | | | | | +--rw cleartext-\ symmetric-key? | | | | | | binary | | | | | | {cleartext-\ symmetric-keys}? | | | | | +--:(hidden-symmetric-\ key) | | | | | | {hidden-\ symmetric-keys}? | | | | | | +--rw hidden-\ symmetric-key? | | | | | | empty | | | | | +--:(encrypted-\ symmetric-key) | | | | | {encrypted-\ symmetric-keys}? | | | | | +--rw encrypted-\ symmetric-key | | | | | +--rw encrypted-\ by | | | | | +--rw encrypted-\ value-format | | | | | | \ identityref | | | | | +--rw encrypted-\ value | | | | | binary | | | | +--:(central-keystore) | | | | {central-keystore-\ supported,symmetric-keys}? | | | | +--rw central-keystore-\ reference? | | | | ks:central-symmetric\ -key-ref | | | +--rw external-identity | | | | string | | | +--rw hash? | | | | tlscmn:epsk-supported-hash | | | +--rw context? | | | | string | | | +--rw target-protocol? | | | | uint16 | | | +--rw target-kdf? | | | uint16 | | +--rw server-authentication | | | +--rw (ref-or-explicit)? | | | +--:(ref) | | | | +--rw credentials-reference? | | | | sys-tcs-plus:server-credentials-ref | | | | {credential-reference}? | | | +--:(explicit) | | | +--rw ca-certs! | | | | +--rw (inline-or-truststore) | | | | +--:(inline) | | | | | {inline-definitions-\ supported}? | | | | | +--rw inline-definition | | | | | +--rw certificate* [name] | | | | | +--rw name | | | | | | string | | | | | +--rw cert-data | | | | | | trust-anchor-cert-cms | | | | | +---n certificate-expiration | | | | | {certificate-\ expiration-notification}? | | | | | +-- expiration-date | | | | | yang:date-and-time | | | | +--:(central-truststore) | | | | {central-truststore-\ supported,certificates}? | | | | +--rw central-truststore-reference? | | | | ts:central-certificate-bag\ -ref | | | +--rw ee-certs! | | | | +--rw (inline-or-truststore) | | | | +--:(inline) | | | | | {inline-definitions-\ supported}? | | | | | +--rw inline-definition | | | | | +--rw certificate* [name] | | | | | +--rw name | | | | | | string | | | | | +--rw cert-data | | | | | | trust-anchor-cert-cms | | | | | +---n certificate-expiration | | | | | {certificate-\ expiration-notification}? | | | | | +-- expiration-date | | | | | yang:date-and-time | | | | +--:(central-truststore) | | | | {central-truststore-\ supported,certificates}? | | | | +--rw central-truststore-reference? | | | | ts:central-certificate-bag\ -ref | | | +--rw raw-public-keys! | | | | {tlsc:server-auth-raw-public-key}? | | | | +--rw (inline-or-truststore) | | | | +--:(inline) | | | | | {inline-definitions-\ supported}? | | | | | +--rw inline-definition | | | | | +--rw public-key* [name] | | | | | +--rw name | | | | | | string | | | | | +--rw public-key-format | | | | | | identityref | | | | | +--rw public-key | | | | | binary | | | | +--:(central-truststore) | | | | {central-truststore-\ supported,public-keys}? | | | | +--rw central-truststore-reference? | | | | ts:central-public-key-bag-\ ref | | | +--rw tls13-epsks? empty | | | {tlsc:server-auth-tls13-epsk}? | | +--rw hello-params {tlscmn:hello-params}? | | +--rw tls-versions | | | +--rw min? identityref | | | +--rw max? identityref | | +--rw cipher-suites | | +--rw cipher-suite* | | tlscsa:tls-cipher-suite-algorithm | +--:(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 discontinuity-time? yang:date-and-time +--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 +--ro cert-errors? yang:counter64 +--ro rpk-errors? yang:counter64 {tlsc:server-auth-raw-public-key}?]]></artwork>]]></sourcecode> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>The document leverages data structures defined in <xref target="RFC9645"/>.</t> <t>Thanks toJoe Clarke and Tom Petch<contact fullname="Joe Clarke"/> and <contact fullname="Tom Petch"/> for the review and comments.</t> <t>Thanks toReshad Rahman<contact fullname="Reshad Rahman"/> for the yangdoctors review,Tina Tsou<contact fullname="Tina Tsou"/> for the opsdir review,Ines Robles<contact fullname="Ines Robles"/> for the genart review, andRobert Sparks<contact fullname="Robert Sparks"/> for the secdir review.</t> <t>ThanksMahesh Jethanandani<contact fullname="Mahesh Jethanandani"/> for the AD review.</t> <t>ThanksErik Kline and Éric Vyncke<contact fullname="Erik Kline"/> and <contact fullname="Éric Vyncke"/> for the IESG review.</t><dl> <dt>Authors<t><contact fullname="Bo Wu"/>, <contact fullname="Guangying Zheng"/>, and <contact fullname="Michael Wang"/> were the authors ofRFC 9105:</dt> <dd> <t>Bo Wu</t> </dd> <dt/> <dd> <t>Guangying Zheng</t> </dd> <dt/> <dd> <t>Michael Wang</t> </dd> <dt>Acknowledgments<xref target="RFC9105"/>.</t> <section numbered="false" anchor="acknowledgments2" toc="exclude"> <name>Acknowledgments from RFC9105:</dt> <dd>9105</name> <t>The authors wish to thankAlex Campbell, John Heasley, Ebben Aries, Alan DeKok, Joe Clarke, Tom Petch, Robert Wilton,<contact fullname="Alex Campbell"/>, <contact fullname="John Heasley"/>, <contact fullname="Ebben Aries"/>, <contact fullname="Alan DeKok"/>, <contact fullname="Joe Clarke"/>, <contact fullname="Tom Petch"/>, <contact fullname="Robert Wilton"/>, and many others for their helpful comments and suggestions.</t></dd> </dl></section> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA+1963rjRo7ofz1FRflhOzHltvuSbmWSHsXtTrxJX6btJDub zTcfRVEW15KoJSm7PY7n/77FeZZzXuwAqPuFFCW7LzvT/L6kLbIKhUKhUAAK hYqiqFNl1TTts+6A/XXw8nv2LK5i9iIfpVM2zgt2mhazbB5P2SBJ0rJkh/m8 KvLpNC3Em0i8YSdXZZXO2OvpsmTbp4PDweHJlzvdTjwcFukFwCfoBJJ/Y/kF ADn96aTbSeIqPcuLqz4rq1EnH5b5NK3Sss+e7N972OmM8mQezwDHURGPqyhL q3GUL8r48iwq02RZpFEVJ3FSRlfx/Czav98pl8NZVpYZYHa1gHrHR6fPO/Pl bJgW/c4IGut3knxepvNyCY1UxTLtAIb3O3GRxoDpq0VaxBXULlk8H7EX8Tw+ S2fpvOp2LvPi/KzIl4umYmwAcNivUDSbn7HvsXi3c55eQeVRv8Mi7DT+M0ov siRlM1URX87TChthOUHPC3y3KPKLbATUEh/x3WAwwH/iZTWBmllCmMg3eZH9 Xb9IknwJReZnnQ7/iEh0GDzj5XTKSfsin8C/I/ZdvkziUZwV9D0vzuK5ANVn rwqgb0ofYMChUjrKCEN40lmcTftsxsH0hhLMn3Oq1Evymd/odzn7dRlo6Idl fJlmwHvJZJ5P87MsLa1GpkCx3uVymP95QiUJ+jwvZlD/Aga3k83Hxq9OFAEV hmVVxEnVQUink6xkwFZLGq5ROs7mKYxie25HIEGGZ8k0Q5jE7bN8tJymrJrE FQzLGTZWwq9UVEUgBteMcObNcObtCpRGLJuzN88P2Vf397/aZVXO4uk0vxSM U+KLWXxOI7IsU5aP1dwq0wJmV0nzLQHgRTzN/g7wBha77NJvxSy7CAhZeaA4 hm0Dn+302MkiTbIxVJtOrwCRGvKZnQ7NdLbfu98LDICa8dRZnPQ9PmizbDSa pp3O54wdI91Hy4S4unOqiBimILu+/gxgId1ubhSGZbqIYVIBcss5AQKqVFdI xnK5WORFxaY5dJFo8Cad5VDSJhh7lsHn4zn7GQjMToDIOIG33wyeHf98suNM xj71lEo6UEi89vFrn7FninzTrKxwEJdYBWdIyS6zakKsDwNTlnmSAfYjtoC/ UZhwwRMzEGbj7GzJpRGbpvEY+zSCIRulxG9QNi0EHGCpy0mWTERfYZg4+g72 DAYIEBnx8RJFDjlzm/j76IuykgURCBtesVi0L6Sey5nUaRsFaPr6+ikMI3KE MYw2o213aUEoiRvkSrCASdndqZ15bZgGEcQaWjzTBLvdeijEA/QBxw6mc5UW c5JTOGIO5XjnDx4/gs732OnVQs+/lNX2WtJFjB/ClfyRoogTc1LIKRjoWA6J MQ9G6WKaX1GnSxiluMhyzozWmMWONLGWnl3OnFqUiG71cPa2kx9EeqxqIw30 vL6GlT/iRW9udnaBq5PpcmSWNYWOqggjfBw965kqhKBdNS337xOda0STyYo9 LoFMfGFa2WIRiQ6LEElpHLCXYmF/YSz3jNStEhZRkDRFMsmqNKlwnLZfvng2 2DGXAc6bj+8/OKDmP/+cHU5wZS3ZCfQ9VZJTiFckIK4VSJFEFJzEwGbDNJ0D YUc03GafuLj6gg1GI8UGJMSBhCvJpquSNMKlNgMaQBOoZBViDUQySCkhmRzZ dJ799zJlCxQAo1EBk2iPWucaGwf98wL1NoIwSsukyBYkpADQlqizha0NU2oe 2sAhIIbFKqgGcjjPs7eA4mwJSJQVQKShWs5RudoyZtGWLp0WRY54zglS+jae LWC4hUpGQzNYLNL5CIoOEB+TpgZZ5qoqoJlNoY2qkD0Si/cvb57rCvP0UtYo 66sIZscxIjk2BzlWdjrP0go0JcCOOFSOP6i3RH7JUOYU4ix1RAodrnEvcfHb PiWKFrAUXnAhjlzGC+10Ot/yUoK/9ac+n0MAXi4klQVnAdKkwHeL5XCqZf2p O32gD6BbL6Zxkk7yKQ7RRTxdIjmQmeYpF24EmAqN+ICPUT6TfBLFBedV2Yxo ZrbKMZ1jN8rlbAZy7u9YYTrFglgJTIkSLKQl1/P5egJkxMZpbXwNqy0MRbxY TK+ogp52Aitae2ByfcH+HR4WRd9SOVjCszOc20g3zuliyQGEYLJB+RN4VpZf PTW/YKffPWM+IGOOcX44EQP2FXZ+NdSDewcPov2DaH9fwwbpBcxDU1UQ0KA2 f2UMMip2sFxe4BoizSjSJzL6zYUsGE6MKzvdFz+fnHZ3+b/s5Sv6+83RX34+ fnP0DP8++WHw00/qj44ocfLDq59/eqb/0jUPX714cfTyGa8Mb5n1qtN9Mfhr ly9j3VevT49fvRz81PUFPfID50MQeWmxKFKcYXHZ4YJqyKfbd4ev/+//2X8g 5PjB/v4T0DGEUN//6gH8uIS1lLeWz4GZ+E8g4VUHuCuNaZCQM5N4kVXxtNxF JaKc5JdzNkmLFJjxi9+QMr/32Z+GyWL/wbfiBXbYeilpZr0kmvlvvMqciIFX gWYUNa33DqVtfAd/tX5Luhsv//R0Cosii/YfP/22o5a7ihQztBavaF4I4uNE JCGo1Txac/TKigCE4vfk4T21tqvhBUnLVUdsobSXZDljDlrMGBpZXeU+VsGV 4vGTe19Rq1tcSdkCwTHGlRF4ytZ7dlFxhwVki6+doYL8Cxfmp0WaosFyVsSz UtMJ3474W64gegzNRRjvNIhGPndFvzvcguCLHGgjnGCfw7RFqSInvURHO5O0 1XcL9RRh3EpDJQO3lZLKXJtN44tAYGXJSMrFZLhs0ccCbTYCKA00RyXm5jsR VtjstAzG3JTAiunbNFlWqMTAYjQf0dp1gX0DIwKWzQsY/jNYxNMLYOMONwq5 MBeLMIL0+nSepgtotIiTczlAIKgBGNi+8DtWuFxOclASS4EQQiV1C6nfUwy0 0vCw7K2tPSjZ56W3gC7cnDUmkWvLKDBKeUNNgOAJ3D09jRxy0NEeIQiTAtTp Xc03CeheqC6RvbsrjKxdxh1Xkt8c4xfIqYYYSVMSbeIKEFxUxpiJkRQtgYJU wtAA87FZilpXVs5ATKe9s94uKcY0qIzEF60VY9AP0AKnIbhMh9EwLqUtrApo 0quJj1rcrjDjceZmBUgVWDO4IhskktCnkD1QmTINdtdphDiS1BPtRag+bwnO H0EloPUyKyew5FWXaE40e5UclxICIa8StYd+rB51LmAYoBwv0hH0Kp4nV5wO v0JL2EOUFvDfbDmtssXUoGeJXZ0DPfis8EUKjTtvhZvSZb4sYByEHYE45Mvq LDeNyQXMnbRC0MspKMI06CX3iaUj5KUQIFlYl4RSwKtnE8k3mgmOX6tqZVrR tKVFDOY8VBsX+Yw7cpbVEOg40jURjPrMXTrP8+IyLsgYPpaOUODp71BR3X5+ /N1OD4toymh6EABhH8Tsl6wgde41IIETQVqw27+8frmDDA3/sjeAErYEg4xw jLa3wZ7ZAUhgZ6GBiiqztAQUQUzexoUGeCsBS04xq8nRJvMjd+CEmk7FcpqP EVCRxqOItCfiNukBLUlNA6rBNEmJoDMgdIw2EZFOe9D4AqdWUYFbnV9TcBSK TBr+qlhy851rZbRO4noboS/iIksvabH8xz/+0REykhnSEf1pX0ZRccmMqct9 Zvw1by1KAEmcbKABfsF+y0a/s2v9KiKVIAV63zzldf+Q1bMRCz+AtpiWRult FIg08Xc0II5KfztJi4q8wVW6Y36E//d6Pa94EV9G3AyIQJnfYdegESV90Z0M MY/sIjdPW0AltSqCle08CFF/tqExAxrvqhByd0jXIEWTOEK6lZ+p907HeDHg ljbFbIKVnwkSiL7Q4NXSNAhQ06t8KrqBa92VQzsWaMgntUlYICbqRb93JAD+ kXSl+sckoTtS0ptjYWZMmihUjkMY5TOQKxE2/pT5D4icqm+UcdufZxGomsNp OgrVHub5NI3nTiUp1mseanKSl5VTjZTc+oeqYZlIe8mM2tu0MQoK3o5JKDlv rJd/OPKFpg/U/MwppEUDzIUoL6L07QJ4K6ukgDBLMjn107Hb2B8GNtiqnnZ6 koUhGkwIIjOqxHD3fcGIkFaBaJzdob6o/gaLsHrJ6ZdktYI0WNacsPXAHDHb DI+x9mL4FjgZQrqhKKvDx5csdfV9XCyR4W6Tu6A+Us72l6YPydnOCuYXa+aJ 4Pq2GRB39WuAxSnScnHcDJvA0skfYwH168qncT0N8vQknU7zCLeyZyWvPpv3 zZded0xUI7SuyL3qlVEtzLI59kQuBT7PWYXjtysLCwbKFmC4ReUyq9JA88Fy XwTLyQc7X8Z97JZZKYqnZ2CAVpOZt/zlw/Gy5GLAYnfVeDkBu3KEkUVFWpnj GVRJtrnNF5D31Jr4mi3CS6767KoTtLxni0goD7VwpRVY0xWnlGolG/fVS0ui 8HoXxTiSdttTBzJj0bdsb571RSySKljuuW/2QioUkHAKIoCb6DAIds/DKhTu 3ICZGdK58FlCX/YfWXVyps3JjlGUfxtlJVqY2Rx45SpC6AQaw8f66PKJwFak 135VjXiUL9K5nPBUVdicjx40VkumeZmKemtUi4eg7K1fbRxnU7BIqeIa1QTF W1WTtnSEZrYeo9bVpFHerm98O9aptLoakJyEnsNDK0kCS1XEm3y6RrVicR6o 1VBNPi0WKnQfXPfZ55ZjgVEU5zdd8vmfKD/EK/G5e9PpuCFcqeGJH6XajZxQ 4IS9lYl7cEX638us4NuZhkeLhyY0b33Q7ueLbJ7NljMVkiH2vh48eHRzw2ib aphyFzttgxbxvET7pgdVj+ICtEIeiiBXLyZ3tmQ1LIjOGr4OML7IsHyM+s+I nKxJki7QuSW2q3isAA+cApMO6x/jdjv2UMR1vhj8VW04vIkv2WsaCPYj6Bxs +83rH8sdciu9LtLohJYN8en1CXwKAkSkJURyxA8zGYOmt0HImcS9XaUwWcle 3gWJzvegswqW3Su+54iBL9qXjjQ64c68l2hiH89H0qm9ffLyeIelbyuQW3LL 3RxlDDnQUQTkXhWoAvgkny2oh37YyJZvgG0RXbZ8/XWr3zFjxsq0MvVk3jl0 2EPPzqb5EJmVx1ogxrihM6ddiTlTiu1I+AgFSyZGnNGWYcpTw6951Aa2bJBV 7fVzsmEcirFP17vfYnNPBBJkpRoD26luj6MYw5J5owcjZAyQjEXSFcnZjw74 pNJeX+073kNHAhXUEwl3hZBA0yscYzWvDGmPlDJcG0QpEcVW8p0itX3fyFnb zu4mzu9H9x7B/N4RXSH1NAXpJ8eY0CSHbTZ2BgWLiyAbvTmqvBOEpBBpYn9W fvIZinaRuK8WZ80CSEXhQcBHIIRTUBVgWpcTcmMbdOHbB8IZLGMfRSvYqOiD 9h2rSJN8wffoguxKHmmbWZWXvOyxgY4JREGdtGhW2m9qByiNk4kLmkY5ZA07 pJzkl0gF3qxRkuJnxeaoYAOT0P/7iGFaTDbPW+sMYm2vKXwPg1gXWchmIKwr lQ0SQZ6uSW2dGgFJfC0uK9qewB2qJIlL2i6uxB6fwcDlUqxosa3GdrbdOOBY MTHye8VjR8S2yC68iyjOBjfKxT5dWiW9HZprWushZF/yICFA1ZgcUrNkoyXF vxi+LJi75TKl7mtNyIEEeo2IDRLaxTTmy4zXAMUXSHGqI5BRdbn+3IhhExFk 5mYNj90A04wPo9woLv3AykdPnuzf3OzqMEv7133j18ODJ/rXk0cYAmH8wnod 9esAv/HAD/FGR4+62+Vm9LFTZArrfpLxKFTC9uGB2erBw6+cdg4ePpZ7TaR1 dv50+OrZEfvu6PvjlyffsjGGkdRt5P/54N7Bw+jefnRwv4d1ux2pKIbLs+sO V22lZwHUu/2v4R2FsC9wd7O7LOZ9rN7n063/djbtz8s+KcR18QQIAkT1OHtr OcW+xm25bEZrGFVFWznig3xNOrWohO+/phdK3giVu4sxdDjiOOdnM8BYH306 RUDU9o3TDnUx0A6+v8t2OCnsNuBdQxPIM30WPsDlBbwH2wRSofCI4sRpeA5v GlrGidJXG8OHlvyxI+Q5SsHGja17ewDHzS3fr+vzsdpWX91ty2Ph9D1rah/E QD/YuqTGsVzGgk0nxdWiykP8lDRxLcqbvstGNPO/V8INkTgk8GdFvJhcBdsH G7GseOS51XrVxGgo3+qIDrgokMEW0VPrt3e+or2D+vZ+FADD/UOXIJ90dv/I Xdrc5kNBYZukuLIfyuMbQHBtaYVHmDDgy5WHwbtpv2MfpCOoXTz8yF69Phn8 +j3bXufM4g5BpVCMhO9OdgHEr+mwD3/+aVJVi7K/t4cGI4WWgY6M3e4BBnuX Z3vcTNr7lncNKv4EdgvU/BOe4avyPv/+Z1nl2w4vKCPIWc2JROORkJrOHIrm eUASQtVHDk1IoQOFXtXvlwCVjKj/AK3vzAPyd3x7JguZkIiQxrEFTkwzGnIh DVPntJF97qUniGSHRW+hU2Frl/+LHhH8W4b44t8Ux6v+4CBEMe4K0X/p6io8 F386EbtbuxzI1ovBX7e43rElA3W31giQJiBulDTbf8C2cSJgjPQO/xMjpHeC AdIcBkZJs7ZR0lTjMF9cFdnZpGLbyQ6Gsj+kU8JchklLBV0BJc4VbnCQv0ui zQM7VVBiAnIJg0ahZQJbktINk3MkW3yTouUOPV1y7ZwH2SG6MmwM3gyzeVxQ ADMGDlIIpDhgSz/yZYUcw9Vs0tnRSsbI54rOBS6LEvgPAxQ5ncrl8L9SMXll iCho3Om8lOHMMtIKqc+9gm/SiwxNm+9OnsGcpbK8PtoQgBigBDhLQ/9BL5Ek 0PTbKtlP6RlFjgnPTSlpAFo+uSFyXvyZ4BHxfVtKFVqd0lRLFIF1hCd7dyRJ idqpaAHRIJjY8ePBywE3L8oJhnvRLFPW4hhD6MQwciOVxO1r6Z3AwTvDwbpy 0Lq8vOxlKCsQJR57S9jvkW6ovBvljp6pMEBSLZbHH6xjY+QU4ecmgdHxiMjX QOlURggyep1VZTod0yqAp6fBnkbqzvOKwie7pBJLQjCtvot1x5U8UvaoGvFo xI1e4e4LnveVpaXcw0p9LQQjWJDRgThOY3I9b4U2obf88jrUL+RGbCwf8C76 5ek0rOUIrCtjusDMMkgYDIqmojKuhiWTPEvS2vZ8q1+eMjPiHOtqm/b3GtUM W7uh1gCMSWdIrWFc0kk77lJTA0cH7cyQYuVtM5dBOqAuTFXiWzzBZMIG9Yec r6vP39GJ4dEos9dZqIl5HUCAcF3KhC32JwyXn4wkpoBRahLdNuqwoQXYP3fY qyOKc/6QYlOJsRTRucvXhE8o0BpYofcTkMfAVe62xOj2EY/65s6maVyQK84i LTacjeVwqOB48tkHAtZa4GyfmzQbazpCqcmNh/kk9HG8nJojKj3PW0hQQRiz BTuYd5gmMfVeO7clSOcgqHzkaQwjGpeSaoR7L7CgWWKPkRqYFNpA1Th1iS5P X0hVLIBYaU3I0Sh1TsHm3Lf/y5vnnJxb7r78ltM1mkTS+d12SPmOLXf34dCo yPnK6lL61hhUb+C6DYYJrk11xlj9sXh/l7NV3hhl0JjL2n5073F072H9snbM PZqqUq+pP7h/9f77I9fH0PLY1LGR8MGD1luRL1oknzB98AoQbd5JTNUeXk9j ofZKXD8eY3gEBf1NfXuXIALNZpKPvl6N4WAwENlrcNiWpXGOonE8cLHor5eC xX7CGRfMPACyDtkUT+59xf3wcmqDtlrlST7VZEKhB3OkLrhYUIz+HGaVpCDD H+6JomuFr088h4BqAbP3EPWOmLsq2i2pYzWC2NwzYaKlD6S9Y6x0QyuQ0ofV 7hgjM/uRgVwdOjf1CjNfAqUJgcYQqjuNGTCUqqxwoKNC8RzPp8zQ1jMX5GqC wRvkEOz5LBgOcjY5EJc3/YrRYTvWNU6Y7FmxpaarXZPmS16jKbja/p6NBAlr Sad3+wlNWqCkwBP+MQN6oOvhKNh333W/3bvseuntoRpdlztVRhhb/eIg3YTW 2SSjYlxxt0NaWnlStL4kN2DVdNBGltc+E7uMbAwYp3L2hOZqd2Af0JLjKLf6 DNA5uSmM2Uiqmm9EGdKBCOpH7H2tCtSID73xOm+38WqKDefgV91ebI8dycwd 0G0TgFVMypIVG7eWUG3ew1WRLMT0UtiYAHJSHtILcUAXOgqWFP7CHdgMjV8a fEAGlV5y7Dqik3aBOQa+MKdxc2Mkg6OmwuBWjpjeMxb2v9wgRosvLTEaLeW5 ZrTRt2tizM/fljke4UTNZL4abx6keWeIG0gT5M1Qp6qrceeRoneGO4GzduZL G2E6vltixgQT83leyegmu6pMoUK9wT15MIDQqXW1umcq5OAdjIuCbfdtJU4y UvZd4KRgt8HJCsO9M2zUQVmfUVfhoQ7b3jkuCrIKgWvEyAkZvjN8CO7GWMkg oTtDR2vBAjCGbE5pr0UZ/PJkswbAjvmScUKB+WhuSe5Da5hdxpQeiQnHKN8i 8P0xudEfEQRZUjKM0qggDmnLZ8uTt1u91dhY0lEiFYtzBez08LU5gTDaT+gy KlNAaD1XAVs10137Y9+p6PEjqUxkRVBVGEXt+zUwzMaRdDd0VwSWd7++o369 ef1j1BTMFTC4bI3XjCOrVXl1uGJsVTDjh5WDkGtrEl3p+pCYUIxY9xzU+Tkm 5sDzfzJSIUpBq+Sl6dBahPMIv0bKbACjQWLeVZQvSO1nXR/iHn8l/olGKtlV 1xg2clVvwazb1uMT8TwOO0ZWiAjlDALHvSHLhfgl2/Kr7rJuUvXFjqAx8pFb FbfYRJ3uzpbLbQ19E4l39IuuDbnrFtCer724vJrNUrBTODcGqTHC3C7bvZ29 Xm8PxitMHLc3IWLVQHKrtqAd0cqtV0M7n9VpCvLkGgitDbtT2KTIx4FV8BTC TpDtJVJ2zKzN9mGut8ciUuh+Yu9N2ft/Fz+35l99ULWedQdzMIYpiHvqnJNh 20evT4B5QV9QEdR0UkeibZ77ADU4ysfREOz8XZb1UrCKUC0R6VvQvWueZxAA sG1ogieLqZaYJghWqG1KhAMI7GrMjsXs2GU/xOVkR0GgbEPh4z1kxDgoInhC UdZHXYYwkP52GVmC/X+WFvJoxXORkJpt//js+Q5mlJFpn5k6ymrFnUuFDoET R9Gekd7GMxBrdLrj+SvhBVcnQ36Kryi7tdjp3gbq7ijnuMlT/PlFRf3e3zXi Qg56+/uyMG23HDz8qs++X2YjirTEhbmWMYgvfka12m8OVDlASLf0yGnkcR9P XUE/kENrWlBjaMhJ/YjNAt3Ew97+aqkZFpq8GjdDBC7qDIsSCqRx8ePFcsph ojBM/39F1xOscLOV6E0Qu/TDK3SNy9R6InAJ+Y6mQo8N2DQe8l0u3fMYvUAR P/lMy4o5ISXepoXu8tLdcVMrftqMo0KNEZN5PPVADfiNHj+clPaQiaP3KAAj tcsWYTk9YHyDtQu0jQ4ePuo2jiRm5dLUtgYB2ZUbXyigDKEg4hp033Bn4lIk SWNC+tnyVWEFDHLywwDxwuNXc8N/Uy4TsxGdMPODs4A/LpQf8G3VNJuC1D6V uQXfVmq+jFKeR5SfwcQZs0sn0+YwGm+zsiopdZpGWWRo3lWA0OKUbq/MSL4W D3F5WKQY/JGTY9iAYpxnwisd4K8z1O9OYGnPYFpWV9NUhoxw73QVJ+flyqG4 E2EYFofMH4YqLs5SUCbEsNrDwY/oNw6HfZhPgcFZzX3xseRmHmRta7kkmj8Y Re7X0+N8NF6bFMiZoAes6vuH7bLRY8eAt09qNgQ11B7YFBpd7ZFNelac2+QH 8biDmtQ4fUZQb8xSTkByxfP85vL0rtic84/3xda+GXcbkVwu7VAMUg7jUuXX Tdmh79URrsMPpKCBPJXbfRTLyFTiKsWwddt6ovwsn5+VXqSDsYNNwFHb9p06 9EltM4a/17mbPGnh2Lgi6MRyDWmE8CE9zviqv0lD8MZE3/aVNXnYGtJpGQjo joddAHfQ+Tevfwx02WluRbc9+251l3WVYHeDEBt6alhwjg5TYxwG+qzbrOvu ShnGHX86wmAtYSZlyr+aOBNSwsmp1lK2yNTCsRmDXKjD3faOuSNszEiQWo+1 kQpCt0CUrnGY4cP1zVBeN4udzSkSivOzeJSrq6vzGX69sWQIhgia3QpOfm/A akl5FBwUdTKmnpxcCttTbZXPKZjCoI3nlOc1MCYi+kvN/AbGTCkNF5IXq2WS Ez1Lo1FGFzjRiZ45XbWl7SRjiRPZ83SQEgkBPB3thLTpqYUtimTauM4fDnas aBI+WHoimlf8aPHQ86rw61lUsDbFy3GBVPINXu19QJKmXhQxPTxLzCjnW/0z fgEKyTu6UmWUqph7H2eNXLNFPCBzFoh+OLA7Km8Vc4RrZdiwNWNrwTFoMwh8 p/E1wIzQGMx4xueYZ4jXAJIJbjMi19MZMi5LdF4Kuwer9fZ1jtqqyVSZril9 xJdznuOUunEYVGZmXM2gR8DpR3y12z462qlhwaZR/2dgyQA7sW3umk7xKgeh DhifDQ+UuhXP5l6bac26uqogDK9vyqw6Fg5PCcnLWSkup0pQN6kw6M3hXA7U YPSPmo2d3KCKmzfZDK+dAXb2ko9U7t4Bj7v9rGHbGqHr1rY419ZNLUHs5Iap EcIe42oQLgfbAN8z0xrM6O+lhnYcdd3a/VR775F2Hw32tZRRvt8Y3Db0N1G3 XLBb6+0Uah1yRcfkXqnxyu+SXyi8pVq3qVqZm6r2r8jvKe/MbwKIT62evWvq A6ijzs7vIQKZBw64w1CnEW4ntAK2NhkTlHa4cX470qy1WmyuX2Qm6ymGZrry +rRU21uY1Zvq7+/MBh2/Bxu07mgAf96PERo+dLGBEep35j0boWbLGM/shWUK +R1k0VXmqJ2Lu46LD408ozoJYqmOySLn/oCQWrmE38NBud1ApfBmeCD9eH3E kJl+fA+w9+JiurXSN1kWQIhqeweksIkcLBNbAgeUhwdbOzv20kBRkZGgq82o vLMHjF8BaiQ7BfNuxveEZfKGBkYNdy5++zF3Ln7bqnPBkB87qVEo5EcXp/BL wfzK3ygFuMxoYhxRoZPnI3l2FGuT2J+bKUwxxle4Kg3jxnAPB3wvwS2pBv2e 8Ix42krXv47G/weyb9tYtq2V/Ftuv63jsbYV5Trnetiea3L4ScUvvBrmhtMt N/wbdlQdKG6uyZibGxXlViMVb6mgNK09KwgTWHp8hdERzc0csfEyJXphtlSn CPoHztueaNTHGP0J7kNdKXPBPvBPufvHQft4GaM7MOTktWQ1Suq6M6Yota2S yGDDDGYAHtaptvng7xkHy3e3nBS9ltivE/pd2hdy0rQIm50cliKzZM1lOEgy OuO/a1yaGDhbDuQOOBhCYqdWWVuB6NxtVuBlthe7p76b5N/NCq4XXGTd7Weq kTxbnkpqYB5Uxfwh/oZNzX7pCj0cnR1ddaq4gX7ri26TdKFtwAbhbVYdqGs6 A3tLZhS6TvHstWzqA17GZ6PvmHq0L0LVImgEFooiM7fqyRDKRpZCFAj+qqcj 32BWyd0K3gOeIQhTkssPpd4VtJdkpROgpBYbo/LW2bBxaDpIVm9/Cf7ybbGP h7+WpZ0yx3Fhh9WAj2dwrzzvNj5mtzcf2hYGpTXARl9ppDChk2mk8sxVXXmh IKrzxmex8RgNaUyKlWP8U83tv+bOmrj72XU+UH7+Ww2MfQ2CjL70B8e6o1Y/ Mp5hxdDYlUgFl1cLoBrN4+mxih1Tb+TTCo+uOL/p5oExaFGTMMYkTjjCu5Fs Iu0+Quo7S+SelXlkz0ioEs9HNh1kRitjW7ts6KdBDb+f7oWZrbrRfAuHc5W9 5aby/fUE8E6cIvzZyDUiqqobQ3RkXYCeRppBn57i/iuLT8jCAW3VzGFo1Wxy A9BkM6ks1SSZXowijuNzOleib/hw+xi88MMem5s2Q39EHeeOQdngy+NdrhiI nDo4HXrsWVaqojY2dfUoIUlrfsGLSfqrYiqP5FUsZqZL+1FF+K02tDtTGmGy dr3/VZwqF5rwrMerZm4pz06ty2vQKmonCBw8afzCSBo35N4BrkbOP3/ldFab Z36eQLIvMHVrcqXqwlL04IkzUJcTvJ6B73CefvfMSXIYJoTYslDpSa9v11s1 D2ZpMonnWTlTuyFODhxKMxwQ1TKA1JFUdS0Kh6WhDFBXNBekbxGRM9tEwCc8 x+92VWgz2xy0pHNceEvrJCWRybiT0iEXXzHMGymdApbu5X1DAPMzzIW13+uh S/prp8CN87t+eMQUEGfEOC674nQCjNr5HDNso0aVV17aJP7UM44zk/yq8QjG DxMyIxuX8gI3fWFabONFqlwACjr16Q46QRWYw/uPMG6riJPKjPrTzzHNwkl2 NpniJTV4owDP1qq9r3bTWRlouMKBhHX3/oHRGpvmXD2jPFJZglSZXomsHW99 KKSfYh/eIuIyGWylIfLI+4DU50FJy8WCwhDLdBeavlR/U+bTLNn1NUV8Fngy dcn1adADcplkgXfdFxOh/g/TsjLyvMcl2zJYnt8Vhwr5FkxjvLcCXwaoWKJM HOUp196FAkNns2agMwH/j5dTSqd7hjgF6ECR78kV5cUq0sWU3CPQI3kLmlfh VKsp5hyl43AL4AYejYLZLS5Cx2ZwjQCBHQQMMITMNi46k8HVMwo3QVs6oTss Rk4qEDGs6DWZoh6JOTtduVgvGeXJktoEmH5TdypL2QbiNOQxgL7bhW6CQtZf JPWVve1OIZDgE0n6ha5ClXFhzpfVENPJKyIu8C6Mqgyshuq236CQr/loajP6 QmCXOI1y29mP5x0x9C7T7Sm7E5g8oX7V0dzpsbqPp6HjNWVk/50bi29BAN0S ZQ/QN6xpkgTmWinzUsiTdzK3kaCnyQv1a99aRHTUXPNWZl/ddVNg8kckwgxf 1+y/pHe218lGju+pbOOmCu6fuLdQU8YKP45L72+zb9ieOZSl9cuv+Rt8Jpvg G6Zg7AVa/t2vin0ZZvNRBPY2gnB2zlcYzZisWxGbei1iYynnOr/gSX3nBos7 6oIxFI4bmMs24/7y+iV7AzwmvDp4EvkyLiiZ5zbgu6MQsjFBx1rJE0vBWrKc c8es8nY1WjHH40C2cpwMxukjrgpcxNNlyu+3tUE00I0LTplUziGXDWX7IouZ NZytLf11b+pyx4dLKffe8la+G3X8n3wT3Vaml5/quyEhGp6L474km1xyx3ZN J1q9SmAeHL1fTyaZhd4jDj/17MxAuqYpaJuYswM4tipZF3TNfD4qu0H6PmxH 21MzFx0TEPUpPeFEvsymU3YZZ/wag9imLCwPixzvz6HFg+4WdTYih+kYbzmr CopW4Vq7DUPr7k2+Db6HoJLk1kSiiesjrWzHUtKFYnPkbZM6TazQNvVND8Ze ur4O2sobZRT5mhC5ERdMHr18dvItXVHe+Zypy8ZAWzw0A3tKfrslZQjMjUJW 9A/ddJws5ZlDfbfwoxb3MeNlUNMrMQ2Mu6joLlHl3PCR4jaNVPKJMGiwjCsx DYFcC8xtZ99aZd4W/RVi91RhBzIPoETFOHn84N5Xw6xUd3vy6zfjRNxS17Wu BRqpxNE0AsIe4NslHfO2dkwfTGo3/EQRiUAiNAdG5lViMptCuSsye5Sdl0en h69ePhd3eT86wItLaVV5c3Rifnl8Dy84lTleV4Bn2/s7/CxElXf4jR7CjaPv nZ6So3WbZ7Y9OflBtPPg4CFdlorqv2iZrobnZulffj4+lNeO37sHCPGL17cP VHO0xs2WYKpOna0RQe/2l1Sy7ZeDwxc71l2wyPvqkjYy0UDUlyJHM2b9qcQ4 EM/hlU5ZspzGsMYIOnP7UBEXt+hKvtWOhqRx2GY5FGcvMNdzfBFnUwrHqYGj 8mTk9s1+lI+E+P0Urz2jA7yxIfuMe96Nu3C966lktt4O7s4iHntJkcb8L5wb 9Jc89dQVmcHRy9g1fEOoGwlJvSPuSJPg3Pvmp9k57v/xG2lKdKzT0Uog6cVy Ok95ZBJdmTbT+kQ6v8iKnN/EBfB/xY3kjkEPwWvpKKsijiLnHupAalKOqyIl R6vD0ZJRikBp9J9ohwFl17bjVDD4gfgRr2U6o2urOynI+oQugZH4GnEk3MUw Bvs5v6R4iOWwKlJxo6emTYeAGlwlSUNJY/YkbbIp/e6Tw0FecUM7F33hcuDh KjzgRVwjowcAPa9inSBlkU8JX0cM7hGzn+dyC1JBETOCqKobX05HQmmhSB9K ZoPiFeZCWYKUVnlrBRSJCHkHjGUa2l/k2VzeJxdTPViU6fY6e9tYZNamwL6c 36DHkZeZzPH1hLxJPLcOi8+QQpWh14t+CtqaLlmHxDInEV0lXvGrGgUMz0va 5BQ1CSpIqUenMppCgtIWnkEcY7ogbXivpAqBWiUpKbvyMCsdXZOSjO6iIqri MuW6XLr24MrR8W7U5nKzJ3LogUzj919khkO1I1Uqz62aiviPcpXvVA5wwIO6 rsO0vZfUcopyhnDCeLhPcysYASLZBY+Wm5c5cibGyA9yT1o5CfAtRtuMihgT StG9fLBASLUEA4JpKeZ+aK7dLPJpllxRwiomrnuLS5HegeEKR7nG+N5l1w/F 6WrGgMHr1d2uru9UJ4WY3y9glBLqNWcPIWjoDXaHh1+QDkaY18r7sKh/g0RC AmkF7GHvPqmH6vp1cSt6+PtD+I7rtZWpi4QBX7w4urfHFLVOupLS1TiBEeg9 jY5M3IHKDF30RSOlF4ef3xxLB3F3XnZxsZD3VIpQmA6f3OLS339/8ROQiBfo ill5/9Hjxzc3fboZ/h9YHICC5NrgfnZSQzh0vHL0kN8T3Ocr2vHRyffkSgAc 4NXLvcHXhJjuJHWGYj0RTXVVfI8jVksY3mHB9po01pWagkT07gW9Q3AYwgBE UxTj9Hh07wC0STOSqOvcBWpUIV43aIcgoXcNBHop+7U5jV/TTYdQ3wwvxg8v 8HI5fncrLIVIrafQIB8WITz6TN0qKujaiaKIDWExQJYUt5SoRWhgazO2pkzS VCQMO6F1r9O5vk7f4jVqQEG8YlceyCWgl1zvXBFJrHxBlk9JrD/2ztrY07d6 TN6hrGK6zLUEBTmMcrOl2KPhZP8FkrGDVnPXGAppTveFPd11gsX7yp/RrY0S h0K/KZO+WzPO1o1Eu8Hi/WkOUj8iu0Euwb9zVwCv0Aq2gTEfAAs90zvDow/7 rAvV/4Z197vmjlrXiGrDUg5lrKLCqY7F9p8c9O71DnoHDjBTncJyf4mPxqeT n89f7T95fG//3r2vHj54dO/Jwf0vJ/dPh0ePnQbU3onZxL7ThnBNQZH9e563 5XfDqXJD/ovrPvucMzeDBX2aftOVs8WfCN0bPRWii2IM00HZisaM4BpunmQi MNZ2Gwlt5Zc3z8Ms6frqfY++5lP3kzHKeozVCL8A0fH90Yujl6d/g9ZN/jMc SFRQm/zoHzf3jWARQA0MpmE+tU5ScAojfYlPP02vf9LpZe5ONTLVbaYiTq7g dMQmbnBJ03FS6g4ux6+nZmYq7+jCPMlTGAIML0mFWeicITbAck2/5J4VOqIs wHBtRNbHO7Uyuv/S9RHu9x4GVFBx8zuZ46QfK+0b3W2PHoBCiXfM43Xyn2+y cqvz0UbiNjNkkUuwbK6XcocKqUnvLS8jxZbac3DPS2qb1nfMKTn3jf2wl69O j/ps6z/xhl6wGy6LeEEHwnBNp52Kr54cMKfSN51PK3hIxMhpGW0uY4zYYyG0 AKGeYIkeqFwOZB3jDMXRH1gnsQ7u3dvvj4aP+30HOTrdAALi4P4D671jaBv0 kAU0f3sfmcpGYlxN4RdiZjYVmcajL8aHIpRyolqpkoH8pweh8anJFOKHLJlZ XQCB7wYnR48e/DL46eejb4KldWrPRrSLMpZpQNfE3HjMVgK4JNM0LjAntplw tE0n6KYdlINeYaesHbxoxVCE+Lx26st2xVnhW3CNzXu/BUjrV6KKcmIdDiJD PjsTdhMauZThz+8bUtI6SuwR0EyAECIiJnyQ7EiRsbTxRZkN7nsd7eKWcG1p G99dZyCzBdieUbnMqjSIiFkgOE4Yi/y3wdHJ3/YPHv/t+8MXfzv5YYDZ+52C v7dlQDd4ABqliIDba0XotAjoQ4a+Qr+PiX/r1n5SnTZRKkx4yukgVAmM0mqn TOjTduYN5qhOyDvb1G3nytYBAoJW6p0f5TdLaj8CN6qmU8OhTbvOZmodsbWp YaBMo5Q8oyWmYUiE44eraei4P3598YDUGvjj0YfQYtZUFPzzyfVKQ4YrtlnD 1Rqa1tdWcnLdtZUX32idWrnCrrO+brK6rqsYmE/D8rrh4tp22WgOR/xdgpUL 6xp8ZdTw+Kpu+W3HVKuW3tDCu96yu86i6y65DSvFSvquVvCBB2ZgPEYXj/4l FPxQshdfaN1aHaxrxubh8FDuNg8YOuCXi498vA4+jZc3wR58fAOmHHLB4bIP F/5LDJacXB/xWIWn1j/jWK0wXyj5ZxsDRlsX3M/7fAlK/WmRpuz68zJNIrxB /oYH+uGfDKOo8FTkMqHMKHRMD2Nvhuk0vxRbuPy5K6Wd7z73a3eDOzpW1wjV 5efKv4yi4pI5G7/6g6+/f8F+y0a/s+tQwpebp7L2HxJANmLhh58b9cpvq6uA dkxgHKH+tqFr7difFYTAHdZ/2GCwGf8aRR+eIkRfFN9h155GWOr7926e1oDQ 1HBr11dQqHo2S0Mrxk85eWFw1mqkHXS+Z9AGsGe5vAv0t81miHlWNcK5KWTL rKyq3lwH65dNbKAgyOkVANCmunxajIPs7CQbAU037KlfeZ1u+rXX6SMllW7V RXGIFxaFdXqpnutg/RYdZbKjQQDt2ncBDDesR6ehxFRrB2HdKdfcdGtq09Na jigLuJ34SOejiPeGTPsomZWrGonm5tKBGbuzIl4po+XP63Ddzb0w81zfxLOa AwF/ZrQ6qln8/J+MURQYVohiIBq6gldS6i07SzHwEOokZQF9L4tIvFmNrYCB i+Fi2cyiqm9QGtvgXI2v2/KqCwE9cvy1/NUC1yLH87UtkFXFtxH66nXIrNXf XuzfQ3K2rKLaEtWewgvxZ5Mi494UX9eaeq69u+WVvrO7GXPH1n3V9eKV6blf d7t9I/K8st1aQ1vGz/OyL9u0q0f1/GZD+KBUYwFV+Cl/L85qBzRrOxMxaLqr LpUMYMBbdW56/KSEf1LCQ5XY5kq4+cdmSjgz+GEDJdz8o9U4yM6uq4RbPV1f CTe7ua4SbvdxtRIuu7iBEm4+mynhqv2NlPBaACuU8Np6rZVw5v5cQ7FpaLo1 telp5N9/Qq2heemkZw0NgAikk/YHV0792cVboauLeAVY+wVT/b35gqn+brtg mhUUqrVLjVN6Jd8HoW/XLDFOYeYtMdZYrqwcWCKatMkgAPmEJlljheuaRj3W r+m0kPdr91i0Hqreoml3udmYXoEFp6ajWvat11f1XNdAaNFd5gtgC0Q7HFYt O23r1S87dRDWnX7NTbemOD2NM6LNsuP/3bTsqHG5RWAMPc2swdZef/y/rfVn xfLDjCbxVG0xhzoqAt5/vH0XB8YkLieNCIq7XXCl0tSNsFo9UMoJ8bZ6GsCn NWJVXJylqKPztBNBWDzXz0oY56NxPSo2DF7PDze6/TZYzQaYDEb6zPjyR0AB 0DdT7tgl2caL/x82Jk3Lvrl4e74GoA1uYP9eU15VofRqwcejTbC+8gnXF1RM i9SK4nkyAdIFPMI+/Dbu4Br98f35goO6r+sIxteNTl6Dafx7T33uMvvp3ZKq 5a15hXQAaebKydBVq8Fq8qm0jDQJPozPHCkphGP6aWJ9mlj282li3cHEcu6w +0wYwPWXnLtIf/RTUKN+qxnYbvJ5rmb8FNbPV9Q3mvZ07XfDmgYbvGvONMhU x5jGTYpS3auzKn2WDblsTGXQ5QS2WvjSYzOBA5R8GsY3JWXDl/p4UIzwwZCC 696Z42Oh4wlD9UWeUa+aTOdc86hLO7yKlJav/nEv0vDqb8uUQzs20aRPznmt lWw7wPEzr5iWSs4F3joqzSzL5CZaOvabdERPMKixDqrBotYdj35cnjkD6oGs sFdCfVI9rymkByMQuueXZUrq+JF8wdJ/mFqJE9hXV4EFFhXPidBQmdnrTLsa 6o/QqnQbp0NgRVuJyYplrk1PVu18toEhfwbWr01Q2Khte+1bo9n6XdP31vX6 PdWWKIS3WG/rAuNOsHVx0RNEI7QxJuHNwfaYuI79W5AktKXaHhH5rM+mcnid nd3bDy671eAKdD7wyN4Wi7saVkvjbFk9vI/+YSateoxdkg8ztMzfdbgNSQLB Ae0RuWNc1DP84LiE9pDWwkX+cRt6bLhmvsOxsfa31sJFPpuqIX7k8zrNu4HQ d8GlhoevZTccn9+tkPAdhm2QkD+vN8fD8P6F/YYt8WiI1V6nJ8x1Pt7B0Jr+ yza4+MHga5pK9NTGj7cEEggnb1nzDz+6fH0I8u8NhZaLhhmU3r6+fDaEEIpy b1lV1faD3ttDYDUx8GtBUJjIkPhNocgH4dyJwGw7L5qjHprrqscPglinD9qZ WxtxtxKPmgCI25EydHnQSnI0ngFoA0D+NAIyNupGfRThOlh4Q7sGLtFdjCwL HS1Ykz/pcQ4iBKuGziW0a6v58MLtp7S1iVWHSuNpiAb8P3kuP3ku+fOv67lk H5Hn0vzjw3oumTFBPqjnkllf12dT9tF4Ls0/PqDnkhkj++E8l8z6urbnkn1E nkvz+bCeS/58BJ7Ld4KLetbzXL4LXDb1XHrvP4DnUj0fgefSe9aR758s2Npn ZbCHj4Z83rP16R5payysnpbn3uqA1B2Da2h0Q0tJvW9tKZnvRWc/kKVkvt/E UnJ6UntYr01l+amtzAu27R/la1OXefbBxsQPHxpricQfd6iOr+GkCiIinxbi urH+7W2ctcSuj0v4+OL7MA58XPSEv51afkuS/HFXxsFdMdlq48Cv7hgHH2bG quf2VsEtx5TdpbYXPHXaHpE7xcV4VlgF7wGX1lZBHS7y5/uwCupw+BBWQR0u 8llnmdnAKlDv1XM7q4AFTgKvNW/ZB7UKTDTkEzokfEvOaGUe8KfmyPEavfCO QjQ3ZZ1MbgF+9UHllU3Kc8vvrlPuqeY1WrIPKrdtCc8+t7PnmhqxDq3YaZxD wD/qsxT+4e4Pf5bCOwXuF/wjYP8GjnAFK7K2tq/T6Q9i9Tpjvoa9a2K/8jDt ys7r412tq7QVCsGWvFO4rZtrPJTbpvWVZ3RXApHP+42385FYK9iupg+s6Zhv HZRVRyvr6qkndNJyzbm26sxwAw5rHNRc2ZOmE8V3YGU06ytfhg//B5H+JE8/ ydNQc5/kqXo+ydNP8jSQ82E17u2TQgRhfBLN64rm+qQVK/v+viWzF6m3drOt HGwr2l5bjq3ygH08goutSNHRgMM7E1xOAo+7cDe3EFyBnCD8abmh0S5RiKov PFfG5cUcwmzeN18GapoYq7uNQ6VUK7Nsjl1qmgpW8fhti+Ji+M17jUPFgiW/ qCkpHyREGffpimWjWhRPz/IiqyYzuz5NpHw4XpZccXFmkEKhnMR4L1iZJkVq pRysSb2yXebLIkmDmSuoTfE9W9SlE1EF3KQplMAkW0QiQUoD7HmVFuM4ccUC c5uQ5VRL2bivXjorN695UYwjecPwUw86LPffsr151gdML/PiXBUt99w3e+GU Me4N0zYN6lLGiCun69Iwem5HfrAHEKmyssqS0pYW/OsoK9Fhm82XeNwRWyDw jbqmqqw7EOWLdC6lA1VO8iWS+NGDFRWTaV6mouZaFeMhCOdNKo7jbLoseJtr VRT0b1lxBswbn6WYfGhujNkaFYs0SbMLmVZodcW0KPLCrdamIgwAiUqHs1oQ B+063uzTtSoWi/NAvcaK8mmhFBvXBXY+Z4PkfJ5fTtMRXedXdq77PDNSOvqm S/e6d8VVhKM8WdKNf9MUYOMQMDR99cWE8BvVynQEQopdX3/25vnhk0cPHt7c 9BBAPD8vWZWzf8tTdjiNi/OUbh0/zWfsdVolE7qRHO80L9KLLL2kj0k+I6Qs AG9SEMcj9iaezOK5qoW0AQxBjygFhF12CtoUOwU5h6U6WCpflKOsUAWO54D0 m3w4FVe0Y5GzFFSwShVBNKAEjCQ7gZX1XBeE1UDD0hi+iCeAIPu3tILfMd65 nqkqg2de8aMiO2c/0uWM2NT/+58iS9gvV/ME6COrHR+dfK8r4k322Mt8TDc4 Ptm/97Df6bPvcvbrEv79fgmUuMI7Hv9jksLa1GcvsmQSp1P2K3yA6vZ4s3EB I2ACwrGORRuXGXQFaI59OWeDafqWHcazxRAUjV0Yycmc/ZDG5TS92mVHw2E6 Z4MiS0u6mHMwhdF5lv6Yn+8aY76rB3xX0vXXbFrlc05qGNIrlkOnCyI0AoIf QGbQbRbj5VSxBJUul2fAhmRJ9Tr/H+sgXaQARAEA[rfced] Terminology a) We do not see "TACACS+TLS" in RFC 9887 or any other published RFC. Will readers understand this term, or should it be defined in this document? b) We see instances of the following. Please let us know how/if these should be made consistent. user name username Note: RFC 7317 uses "user name", and RFC 9105 uses "username". hash algorithm Hash algorithm credential reference credentials reference c) Please review "domain-name" in the following description clauses. Should these be updated to one of the following? 'domain-name' (single quotes and hyphen) domain name (no quotes and no hyphen) In running text and description clauses, the convention seems to be single quotes and hyphen for the name of the leaf ('domain-name') and and no quotes and no hyphen for general use (domain name). Original: - updates the description of the 'name' under 'server' list to better reflect the intended use and clarifies the difference with the new domain-name ... "A name that is used to uniquely identify a TACACS+ server within the device configuration. This name is not to be confused with the domain-name."; Perhaps A: - updates the description of the 'name' under 'server' list to better reflect the intended use and clarifies the difference with the new 'domain-name' ... "A name that is used to uniquely identify a TACACS+ server within the device configuration. This name is not to be confused with the 'domain-name'."; Perhaps B: - updates the description of the 'name' under 'server' list to better reflect the intended use and clarifies the difference with the new domain name ... "A name that is used to uniquely identify a TACACS+ server within the device configuration. This name is not to be confused with the domain name."; --> <!-- [rfced] We see both of the following expansions for RPK in this document: Raw Public Keys (RPKs) raw private key (RPK) Note that RFCs 7250, 9641, and 9887 use "Raw Public Keys (RPKs)". However, because the YANG module in this document uses both "raw-public-keys" and "raw-private-key", would it be best to only use the expanded forms (and not the acronym RPK)? Or do you prefer another solution? --> <!-- [rfced] FYI: For the figures in Section 3 and Appendix C, we updated <artwork> to <sourcecode type="yangtree">. Please confirm that this is correct. --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>