]> Orange

mohamed.boucadair@orange.com

Operations and Management Operations and Management Area Working Group XXXX XXXX XXXX This document defines a YANG module for Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3. This modules augments the YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) defined in the RFC 9105 with TLS-related data nodes. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction defines a YANG module ("ietf-system-tacacs-plus") that augments the System Management data model defined in for the management of Terminal Access Controller Access-Control System Plus (TACACS+) clients. 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+ over TLS 1.3 clients . The module is designed as an augmentation to the "ietf-system-tacacs-plus" module specified in .

• Discussion Note: RFC 9105bis or keep the current augment design.

The module leverages the TLS structures defined in . Concretely, this first version of the specification uses a pruning approach rather that a reuse of the groupings defined in .

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 meanings of the symbols in the YANG tree diagrams are defined in . The document uses the terms defined in and . 'client' refers to TLS TACACS+ client, while 'server' refers to TLS TACACS+ server.

• Note to the RFC Editor: Please update the following:
  • AAAA --> the assigned RFC number for
  • BBBB --> the assigned RFC number for
  • CCCC --> the assigned RFC number for
  • FFFF --> the assigned RFC number for
  • XXXX --> the assigned RFC number for this document.

Module Tree Structure 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

The full tree structure is shown below: The following data nodes are supported:

'remote-address':

Specifies a list of IP address/port numbers that can be used to reach a server instance.

A server instance may be identified by an IPv4 address, IPv6 address, or both.

One or multiple addresses of the same address family may be provided.

The same or distinct port numbers may be used per address family.

This container takes precedence over "address" and "port" data nodes defined in .

'domain-name':

Provides a domain name of the server per .

'client-identity':

Specifies the identity credentials that the client may present when establishing a connection to a server.

'server-authentication':

Specifies how a client authenticate servers.

'hello-params':

Controls TLS versions and cipher suites.

'keepalives':

Providers a set of parameters for testing the aliveness of the server.

YANG Module This module uses types and groupings defined in , , , , , and . The module augments , which is also an augment of . The module also cites , , , and . WG List: Editor: Mohamed Boucadair "; description "This module provides configuration of TACACS+ over TLS clients. 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-05-23 { description "Initial revision."; reference "RFC XXXX: XXXX"; } // to be further tweaked to align with the scope of tacacs+TLS spec // can't reuse the groupings in TLS as they are because TLS1.2 // is not supported // can't set a default because of must in a choice grouping certificate { description "Specifies the client identity using a certificate."; 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/keystore/" + "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 the client identity using a raw private key."; 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/keystore/" + "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 PSKs are provisioned out of band, the PSK identity and the 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 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."; 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, of which one must be enabled and selected."; 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 server-authentication { description "Specifies how the TLS client can authenticate TLS servers. Any combination of credentials is additive and unordered."; nacm:default-deny-write; container ca-certs { presence "Indicates that 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 BBBB: A YANG Data Model for a Truststore"; uses ts:inline-or-truststore-certs-grouping; } container ee-certs { presence "Indicates that 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 the 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 BBBB: 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 the 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 BBBB: 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/truststore/" + "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 the TLS client can authenticate TLS servers using configured external PSKs."; } } grouping test-peer-aliveness { description "Configures the keep-alive policy to proactively test the aliveness of the TLS server. An unresponsive TLS server is dropped after approximately max-wait * max-attempts seconds."; reference "RFC 6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension"; leaf max-wait { type uint16 { range "1..max"; } units "seconds"; default "30"; description "Sets the amount of time in seconds after which if no data has been received from the TLS server, a TLS-level message will be sent to test the aliveness of the TLS server."; } leaf max-attempts { type uint8; default "3"; description "Sets the maximum number of sequential keep-alive messages that can fail to obtain a response from the TLS server before assuming the TLS server is no longer alive."; } } grouping hello-params { description "Configurable parameters for the TLS hello message."; nacm:default-deny-write; uses tlscmn:hello-params-grouping { refine "tls-versions" { must "not(derived-from-or-self(tls-version, " + " 'tlscmn:tls12'))" { error-message "TLS 1.2 is not supported."; } } } } grouping keepalives { description "Configures the keepalive policy for the TLS client."; nacm:default-deny-write; leaf peer-allowed-to-send { type empty; description "Indicates that the remote TLS server is allowed to send HeartbeatRequest messages to this TLS client."; reference "RFC 6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension"; } container test-peer-aliveness { presence "Indicates that the TLS client proactively tests the aliveness of the remote TLS server."; description "Configures the keep-alive policy to proactively test the aliveness of the TLS server. An unresponsive TLS server is dropped after approximately max-wait * max-attempts seconds."; uses test-peer-aliveness; } } 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 the TLS client may present when establishing a connection to a TLS server."; uses client-identity; } container server-authentication { must 'ca-certs or ee-certs or raw-public-keys or tls13-epsks'; description "Specifies how the TLS client can authenticate TLS servers."; uses server-authentication; } container hello-params { if-feature "tlscmn:hello-params"; description "Configurable parameters for the TLS hello message."; uses hello-params; } container keepalives { if-feature "tlsc:tls-client-keepalives"; description "Configures the keepalive policy for the TLS client."; uses keepalives; } } grouping tcp-server-info { description "A grouping for configuring the information to contact a TCP server."; list remote-address { key "address"; description "A server instance may be reachable using multiple IP address and port numbers. For example, use the same port number in different address families or different port numbers in the same address family."; leaf address { type inet:ip-address; description "The remote IP address to reach a server."; } leaf port-number { type inet:port-number; description "The remote port number of the server."; } } } augment "/sys:system/sys-tcs-plus:tacacs-plus" + "/sys-tcs-plus:server" { description "Adds server's domain name."; uses tcp-server-info { refine "remote-address/address" { must 'not(../sys-tcs-plus:address)' { error-message "Either use the list of bind points or RFC 9105 address data node, not both."; } } refine "remote-address/port-number" { must 'not(../sys-tcs-plus:port)' { error-message "Either use the list of bind points or RFC 9105 port data node, not both."; } default "1234"; // to be replaced by TACACS-TLS-PORT } } leaf domain-name { type inet:domain-name; description "Provides a domain name of the TACACS+ server."; } } augment "/sys:system/sys-tcs-plus:tacacs-plus/sys-tcs-plus:server" + "/sys-tcs-plus:security" { description "Adds TLS case."; case tls { description "TLS is used."; uses tls-client; } } } ]]>

Security Considerations This section uses the template described in Section 3.7 of . The YANG module specified in this document defines schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . 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). These data nodes may be considered 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. Specifically, the following subtrees and data nodes have particular sensitivities/vulnerabilities: Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/vulnerabilities: This YANG module uses groupings from other YANG modules that define nodes that may be considered sensitive or vulnerable in network environments. Refer to for information as to which nodes may be considered sensitive or vulnerable in network environments.

IANA Considerations IANA is requested to register 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 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 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 servers. This document adds Transport Layer Security (TLS 1.3) support to TACACS+ and obsoletes former inferior security mechanisms. This document updates RFC8907. Watsen Networks 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 providing support for an IANA-maintained algorithm registry. 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. Watsen Networks This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications. Watsen Networks 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. Watsen Networks 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 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 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 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 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] 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). This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] 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 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. 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. 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.

Acknowledgments The document leverages data structures defined in .