]> Orange

mohamed.boucadair@orange.com

Huawei Technologies

mlana.wubo@huawei.com

Huawei Technologies

zhengguangying@huawei.com

Huawei Technologies

wangzitao@huawei.com

Operations and Management Operations and Management Area Working Group TLS device management network operator provider network AAA authentication authorization 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. This document obsoletes RFC 9105.

Introduction The System Management data model defines separate functionality to support local and Remote Authentication Dial In User Service (RADIUS) authentication:

User Authentication Model:

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.

RADIUS Client Model:

Defines a list of RADIUS servers used by a device for centralized user authentication.

defines a YANG module ("ietf-system-tacacs-plus") that augments the System Management data model for the management of Terminal Access Controller Access-Control System Plus (TACACS+) clients as an alternative to RADIUS servers . Typically, the "ietf-system-tacacs-plus" module is used to configure a TACACS+ client on a device to support deployment scenarios with centralized authentication, authorization, and accounting servers. This document defines a YANG module for managing TACACS+ clients (), including TACACS+ over TLS 1.3 clients . This document obsoletes . The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) defined in .

Changes Since RFC 9105 The following changes have been made to :

• Add support for TLS
• Fix a must statement under 'tacacs-plus'
• Fix errors in the example provided in Appendix A of
• Add new examples to illustrate the use of TACACS+TLS data nodes

Detailed YANG changes are listed in .

Editorial Note (To be removed by RFC Editor)

• Note to the RFC Editor: This section is to be removed prior to publication.

This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please apply the following replacements:

• XXXX --> the assigned RFC number for this I-D
• SSSS --> the assigned RFC number for
• TBD --> the assigned port number in
• 2024-12-11 --> the actual date of the publication of this document

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. The terminology for describing YANG data models is defined in . The document uses the terms defined in and . 'client' refers to TACACS+ client, while 'server' refers to TACACS+ server.

Tree Diagrams The tree diagram used in this document follows the notation defined in .

Design of the TACACS+ Data Model This module is used to configure a TACACS+ client on a device to support deployment scenarios with centralized authentication, authorization, and accounting 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. 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. The 'server' list, which is directly under the 'tacacs-plus' container, holds a list of TACACS+ servers and uses 'server-type' to distinguish between Authentication, Authorization, and Accounting (AAA) services. The list of servers is for redundancy. 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. The 'statistics' container under the 'server' list is a collection of read-only counters for sent and received messages from a configured server. The YANG module for TACACS+ client has the structure shown in .

Tree Structure Overview /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}? ]]>

Specifically, the module is designed to cover the following key requirements specified in :

• TLS 1.3 MUST be used for transport.
• Earlier TLS versions TLS MUST NOT be used.
• The cipher suites offered or accepted SHOULD be configurable.
• Implementations MAY support Raw Public Keys and PSK.
• Implementations MUST support the ability to configure the server's domain name, so that it may be included in the TLS Server Name Indication (SNI) extension.

The following new data nodes are supported compared to :

'client-credentials' and 'server-credentials':

Defines a set credentials that can be globally provisioned and then referenced under specific servers.

'domain-name':

Provides a domain name of the server per .

'sni-enabled':

Controls activation of Server Name Indication (SNI) (). This parameter can be used only if a domain name is provided.

'client-identity':

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 explicitely under each server instance.

'server-authentication':

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 explicitely under each server instance.

'hello-params':

Controls TLS versions and cipher suites.

'discontinuity-time':

The time on the most recent occasion at which the client suffered a discontinuity.

'cert-errors':

Number of connection failures due to certificate issues.

'rpk-errors':

Number of raw public key related connection failures.

TACACS+ Client Module This YANG module uses types and groupings defined in , , , , , , , and . The module augments . The module also cites , , and . WG List: Editor: Mohamed Boucadair Author: Bo Wu Author: Guangying Zheng "; description "This module provides configuration 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) 2024 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). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2024-12-11 { 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 reference of 'tacacs-plus' identity to also cite RFC SSSS - fixes a must statement under 'tacacs-plus' by adding a missing prefix - updates the description of the 'name' under 'server' list to better reflect the intended use and clarifies the difference with the new domain-name - 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 - updates the description of timeout to remove redundant text with the default statement"; reference "RFC XXXX: 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 "RFC SSSS: 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 time on the most recent occasion at which the TACACS+ client suffered a discontinuity."; } 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 provisioned 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 a pre-shared key 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. When 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"; nacm:default-deny-write; choice auth-type { default "certificate"; //mandatory true; 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 provisioned 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. When 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."; nacm:default-deny-write; 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 reference of 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 a server credentials."; uses server-authentication; } } } grouping hello-params { description "Configurable parameters for the TLS Hello message."; reference "RFC SSSS: Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3, Section 5.1"; nacm:default-deny-write; 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 present when establishing a connection to a TLS server."; nacm:default-deny-write; leaf id { type string; description "An identifier that uniquely identify server credentials within the device configuration."; } uses server-authentication; } list server { key "name"; 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 "RFC SSSS: 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 of SNI, when set to true. Disables the use of SNI, when set to false."; reference "RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions, Section 3 RFC SSSS: 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 of the TACACS+ server."; } leaf port { type inet:port-number; //default "49"; description "The port number of TACACS+ server port number. Default port number for legacy TACACS+ is 49, while it is TBD 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 "RFC SSSS: 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."; reference "RFC 8907: The TACACS+ Protocol"; 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"; } description "Specifies the VPN Routing and Forwarding (VRF) instance to use to communicate with the TACACS+ server."; reference "RFC 8529: YANG Data Model for Network Instances"; } leaf single-connection { type boolean; default "false"; description "Indicates whether the Single Connection Mode is enabled for the server."; } 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; } } ]]>

Security Considerations This section is modeled after the template described in . The "ietf-ac-common" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These protocols have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and have to use mutual authentication. The Network Configuration Access Control Model (NACM) 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. 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 reasonably 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:

'server':

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.

'shared-secret':

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 . 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.

'client-identity' and 'server-authentication':

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.

This YANG module uses groupings from other YANG modules that define nodes that may be considered sensitive or vulnerable in network environments. Refer to and for information as to which nodes may be considered sensitive or vulnerable in network environments.

IANA Considerations IANA is requested to update the following URI in the "ns" subregistry within the "IETF XML Registry" : IANA is requested to register the following YANG module in the "YANG Module Names" registry within the "YANG Parameters" registry group:

References Normative References 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. NTT Cisco Systems, Inc. Google Inc. 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 RFC8907. 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. 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. 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. 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). 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. 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. 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] This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. 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. This document obsoletes RFC 6536. 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). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 7223. 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). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications. 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. 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. This document presents four YANG 1.1 modules -- three IETF modules and one supporting IANA module. 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. The IANA module is "iana-tls-cipher-suite-algs". This module defines YANG enumerations that provide support for an IANA-maintained algorithm registry. This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. 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] 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. This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3. 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. 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] Informative References 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. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. 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] 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. 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 evolution of the YANG language. YumaWorks Orange Huawei This memo provides guidelines for authors and reviewers of specifications containing YANG modules, 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. The document also updates RFC 6020 by clarifying how modules and their revisions are handled by IANA. 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] 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). 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] 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.

Example TACACS+ Authentication Configuration with Shared Secret shows an example where a TACACS+ authentication server instance is configured using shared secret for authentication.

Example with Shared Secret

TACACS+TLS Examples This section provides examples to illustrate the configuration of TACACS+TLS clients. These examples follow the convention used in for binary data that has been base64 encoded.

Example TACACS+ Authentication Configuration with Explicit Certificate Definitions shows a configuration example with 'inline-definition' for the client identity and server authentication.

Example with TACACS+TLS with Inline Certificate Definitions

Example TACACS+ Authentication Configuration with Certificate References shows a configuration example with credential references for multiple service instances: four server instances are configured with all using the same credentials. These instances form a redundancy group for both IPv4 and IPv6.

Example with TACACS+TLS with References

Full Tree The full tree structure is shown below: /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}? ]]>

Acknowledgments The document leverages data structures defined in . Thanks to Joe Clarke and Tom Petch for the review and comments.

Acknowledgments from RFC 9105:

The authors wish to thank Alex Campbell, John Heasley, Ebben Aries, Alan DeKok, Joe Clarke, Tom Petch, Robert Wilton, and many others for their helpful comments and suggestions.