]> 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 abstract tree structure is shown below: The following data nodes are supported:

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

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

'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. Both explicit and reference are supported.

'server-authentication':

Specifies how a client authenticates servers. Both explicit and reference are supported.

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

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 TACACS+ 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. The document also updates RFC 6020 by clarifying how modules and their revisions are handled by IANA.

Full Tree The full tree structure is shown below:

Acknowledgments The document leverages data structures defined in . Thanks to Bo Wu for the review and comments.