Internet-Draft YANG Data Models for Security Configurat October 2024
Hu, et al. Expires 24 April 2025 [Page]
Workgroup:
opsawg
Internet-Draft:
draft-hu-opsawg-sec-config-yang-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
F. Hu
China Southern Power Grid
Y. Huang
China Southern Power Grid
L. Yan
Huawei Technologies

YANG Data Models for Security Configuration Check

Abstract

Security configuration refers to the status setting of product security features/functions to reduce network security risks during product use. This document defines YANG data models for the security configuration check.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 April 2025.

▲

Table of Contents

1. Introduction

Weak or incorrect configurations are the main factors of network insecurity. Insecure configurations can be exploited to easily launch a network intrusion by attackers. It is reported that more than 95 per cent of the attacks are successful because of missing software updates or bad system configurations. The top 3 high-risk configuration items are default password, unnecessary opened ports, and insecure protocol or algorithm. The default accounts and passwords make it easy for attackers to guess and successfully access the network. The unnecessary opened ports increase the exposed surface of the attack. Although security protocols can improve security, using known vulnerable algorithms or protocol versions will greatly reduce the attack difficulty.

Security configuration checks can reduce network security risks during the usage of devices. The first step of the security configuration check is to collect security configuration information from devices. Then, the value of the collected configuration item will be compared with the security configuration benchmark to determine whether the configuration item is secure. The security configuration benchmark is the recommended value of the configuration item to ensure basic device security.

In the past, the IETF has existing work on security posture definition, collection, and assessment, including the concluded Network Endpoint Assessment (NEA)[RFC5209] and Security Automation and Continuous Monitoring (SACM) working groups [RFC8248]. The security configuration benchmark of the management plane [I-D.lin-sacm-nid-mp-security-baseline] has been defined in SACM. This document focuses on the first step of the security configuration check and defines YANG data models for security configurations to be collected. In this document, the security configuration check will be categorized first. Second, the YANG data models will be built according to the categories.

1.2. Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.3. Tree Diagrams

The meaning of the symbols in this diagram is defined in [RFC8340].

2. Categorization of Security Configurations

Figure 1 depicts the categorization of the security configuration check:

                 +-----------------------------+
                 | Security Configuration Check|
                 +---------------+-------------+
                                 |
      +-------------+------------+-----------+-----------+
      |             |            |           |           |
      |             |            |           |           |
      |             |            |           |           |
+-----v-----+ +-----v----+ +-----v----+ +----v---+ +-----v-----+
|   Weak    | | Insecure | | Insecure | | Short  | | Unchanged |
| Algorithm | | Protocol | | Features | |  Key   | |  Default  |
+-----------+ +----------+ |  Status  | | Length | | Settings  |
                           +----------+ +--------+ +-----------+
Figure 1: Categorization of Security Configuration Check

The security configuration check is categorized into weak algorithms, insecure protocols, insecure feature status, short key length and unchanged default settings.

2.1. Weak Algorithms

Here, algorithms refer to any algorithms used in any softwares or protocols for security purpose, such as key exchange, encryption, signature, and integrity check. The weak algorithms are the algorithms that is considered insecure, such as MD5, 3DES.

Take TLS as an example, security algorithms used in TLS are called cipher-suites.
With the existing definitions of YANG Groupings for TLS Clients and TLS Servers [RFC9645], the algorithms supported by TLS can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the following example:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id="101">
  <get-data
    xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
    xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
    <datastore>ds:operational</datastore>
    <subtree-filter>
      <hello-params
        xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-common"
        xmlns:tlscmn="urn:ietf:params:xml:ns:yang:ietf-tls-common">
        <cipher-suites>
          <cipher-suite>
            <cipher-suite/>
          </cipher-suite>
        </cipher-suites>
      </hello-params>
    </subtree-filter>
  </get-data>
</rpc>

In addition, the real-time change of the above information can be notified on time with NETCONF pub/sub mechanisms [RFC8641] as the following example:

<netconf:rpc xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
             message-id="101">
  <establish-subscription
    xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
    xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
    <yp:datastore
      xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
      ds:operational
    </yp:datastore>
    <yp:datastore-subtree-filter>
      <hello-params
        xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-common"
        xmlns:tlscmn="urn:ietf:params:xml:ns:yang:ietf-tls-common">
        <cipher-suites>
          <cipher-suite>
            <cipher-suite/>
          </cipher-suite>
        </cipher-suites>
      </hello-params>
    </yp:datastore-subtree-filter>
    <yp:on-change/>
  </establish-subscription>
</netconf:rpc>

2.2. Insecure Protocols

Here, protocols refer to any protocol used in a device for the communication to any other devices in any layers. Insecure protocols can be the protocol without security mechanisms, such as TCP and HTTP, or the older version of the protocols, such as TLSv1.1 and SNMPv1.

Common Protocols and their YANG models are listed as follows:

Take SNMP as an example. With the existing definitions of a YANG data model for SNMP configuration [RFC7407], the protocol version of SNMP can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the following example:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id="101">
  <get-data
    xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
    xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
    <datastore>ds:operational</datastore>
    <subtree-filter>
      <snmp
        xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
        <engine>
          <version>
            <version/>
          </version>
        </engine>
      </snmp>
    </subtree-filter>
  </get-data>
</rpc>

In addition, the real-time change of the above information can be notified on time with NETCONF pub/sub mechanisms [RFC8641] as the following example:

<netconf:rpc xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
             message-id="101">
  <establish-subscription
    xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
    xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
    <yp:datastore
      xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
      ds:operational
    </yp:datastore>
    <yp:datastore-subtree-filter>
      <snmp
        xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
        <engine>
          <version>
            <version/>
          </version>
        </engine>
      </snmp>
    </yp:datastore-subtree-filter>
    <yp:on-change/>
  </establish-subscription>
</netconf:rpc>

2.3. Insecure Features Status

Security features include security functions and configurations. Insecure features are classified as follows:

  • all interfaces listening

  • all interfaces binding

  • unconfigured security configurations

    • unconfigured ACL hardening

    • unconfigured keys

    • unconfigured passwords

    • unconfigured timeout period

  • disabled security functions

    • disabled account locking

    • disabled certificate verification

    • disabled allowlitst

    • disabled blocklist

    • disabled encryption function

    • disabled authentication function

    • disabled security protocol

Listening or binding all interfaces may cause the exposed attack surface to increase. Setting the security configurations and enabling the security functions will enhance the device's security.

The submodule "ietf-security-config-features", which defines the configuration parameters of security features, has the following structure:

submodule: ietf-security-config-features
+--rw security cofig
   +--rw security features* [name]
      +--rw id? unit64
      +--rw name string
      +--rw description? string
      +--rw status boolean

The "status" true means the security feature is enabled or configured, and false means the security feature is disabled or unconfigured.

The submodel "ietf-security-config-features" can be used with NETCONF [RFC6241] Subtree Filtering mechanism for configuration information collection. The feature status information can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the following example:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id="101">
  <get-data
    xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
    xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
    <datastore>ds:operational</datastore>
    <subtree-filter>
      <security-config
        xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
        <security features>
          <name>
            <name/>
          </name>
          <status>
            <status/>
          </status>
        </security features>
      </security-config>
    </subtree-filter>
  </get-data>
</rpc>

In addition, the real-time change of the above information can be notified on time with NETCONF pub/sub mechanisms [RFC8641] as the following example:

<netconf:rpc xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
             message-id="101">
  <establish-subscription
    xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
    xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
    <yp:datastore
      xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
      ds:operational
    </yp:datastore>
    <yp:datastore-subtree-filter>
      <security-config
        xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
        <security features>
          <name>
            <name/>
          </name>
          <status>
            <status/>
          </status>
        </security features>
      </security-config>
    </yp:datastore-subtree-filter>
    <yp:on-change/>
  </establish-subscription>
</netconf:rpc>

2.4. Short Key length

Short Key length means the key is not long enough to meet the security requirement. The submodule "ietf-security-config-key", which defines configuration parameters of key length, has the following structure:

submodule: ietf-security-config-key
+--rw security cofig
   +--rw key* [key id]
      +--rw key id unit64
      +--rw usage? string
      +--rw length unit64

The "usage" describes the key is used by which algorithm of which protocol or software.

The submodel "ietf-security-config-key" can be used with NETCONF [RFC6241] Subtree Filtering mechanism for configuration information collection. The key length information can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the following example:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id="101">
  <get-data
    xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
    xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
    <datastore>ds:operational</datastore>
    <subtree-filter>
      <security-config
        xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
        <key>
          <key id>
            <key id/>
          </key id>
          <length>
            <length/>
          </length>
        </key>
      </security-config>
    </subtree-filter>
  </get-data>
</rpc>

In addition, the real-time change of the above information can be notified on time with NETCONF pub/sub mechanisms [RFC8641] as the following example:

<netconf:rpc xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
             message-id="101">
  <establish-subscription
    xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
    xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
    <yp:datastore
      xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
      ds:operational
    </yp:datastore>
    <yp:datastore-subtree-filter>
      <security-config
        xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
        <key>
          <key id>
            <key id/>
          </key id>
          <length>
            <length/>
          </length>
        </key>
    </yp:datastore-subtree-filter>
    <yp:on-change/>
  </establish-subscription>
</netconf:rpc>

2.5. Unchanged Default Settings

Default settings required to be changed include the default security-related configurations set by manufacturers and the default port defined by protocols. Unchanged default settings are classified as follows:

  • Unchanged default certificates

  • Unchanged default PKI domains

  • Unchanged default keys

  • Unchanged default ports

Using the default certificates, PKI domains, or keys set by manufacturers may have a risk of being cracked. Using the default port number of a protocol may cause being sniffed and monitored.

The submodule "ietf-security-config-default-settings", which defines configuration parameters of default settings, has the following structure:

submodule: ietf-security-config-default-settings
+--rw security cofig
   +--rw default settings* [name]
      +--rw type enumeration
            {certificates, PKI domains, keys, ports}
      +--rw id? unit64
      +--rw name string
      +--rw description? string
      +--rw changed boolean

The "changed" true means the default setting has been changed, and false means unchanged.

The submodel "ietf-security-config-default-settings" can be used with NETCONF [RFC6241] Subtree Filtering mechanism for configuration information collection. The default setting information can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the following example:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id="101">
  <get-data
    xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
    xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
    <datastore>ds:operational</datastore>
    <subtree-filter>
      <security-config
        xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
        <default settings>
          <type>
            <type/>
          </type>
          <name>
            <name/>
          </name>
          <changed>
            <changed/>
          </changed>
        </default settings>
      </security-config>
    </subtree-filter>
  </get-data>
</rpc>

In addition, the real-time change of the above information can be notified on time with NETCONF pub/sub mechanisms [RFC8641] as the following example:

<netconf:rpc xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
             message-id="101">
  <establish-subscription
    xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
    xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
    <yp:datastore
      xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
      ds:operational
    </yp:datastore>
    <yp:datastore-subtree-filter>
      <security-config
        xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
        <default settings>
          <type>
            <type/>
          </type>
          <name>
            <name/>
          </name>
          <changed>
            <changed/>
          </changed>
        </default settings>
    </yp:datastore-subtree-filter>
    <yp:on-change/>
  </establish-subscription>
</netconf:rpc>

3. YANG Data Model for Security Configuration Check

4. Security Considerations

5. IANA Considerations

6. References

6.1. Normative References

[RFC8340]
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, , <https://www.rfc-editor.org/rfc/rfc8340>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/rfc/rfc6241>.
[RFC7407]
Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, , <https://www.rfc-editor.org/rfc/rfc7407>.
[RFC9645]
Watsen, K., "YANG Groupings for TLS Clients and TLS Servers", RFC 9645, DOI 10.17487/RFC9645, , <https://www.rfc-editor.org/rfc/rfc9645>.
[RFC9644]
Watsen, K., "YANG Groupings for SSH Clients and SSH Servers", RFC 9644, DOI 10.17487/RFC9644, , <https://www.rfc-editor.org/rfc/rfc9644>.
[RFC9648]
Scharf, M., Jethanandani, M., and V. Murgai, "YANG Data Model for TCP", RFC 9648, DOI 10.17487/RFC9648, , <https://www.rfc-editor.org/rfc/rfc9648>.
[RFC9061]
Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, "A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)", RFC 9061, DOI 10.17487/RFC9061, , <https://www.rfc-editor.org/rfc/rfc9061>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

6.2. Informative References

[RFC5209]
Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, , <https://www.rfc-editor.org/rfc/rfc5209>.
[RFC8248]
Cam-Winget, N. and L. Lorenzin, "Security Automation and Continuous Monitoring (SACM) Requirements", RFC 8248, DOI 10.17487/RFC8248, , <https://www.rfc-editor.org/rfc/rfc8248>.
[RFC8641]
Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, , <https://www.rfc-editor.org/rfc/rfc8641>.
[I-D.lin-sacm-nid-mp-security-baseline]
Lin, Q., Xia, L., and H. Birkholz, "The Data Model of Network Infrastructure Device Management Plane Security Baseline", Work in Progress, Internet-Draft, draft-lin-sacm-nid-mp-security-baseline-04, , <https://datatracker.ietf.org/doc/html/draft-lin-sacm-nid-mp-security-baseline-04>.
[I-D.ietf-netconf-http-client-server]
Watsen, K., "YANG Groupings for HTTP Clients and HTTP Servers", Work in Progress, Internet-Draft, draft-ietf-netconf-http-client-server-23, , <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-23>.
[I-D.ietf-netconf-udp-client-server]
Feng, A. H., Francois, P., and K. Watsen, "YANG Groupings for UDP Clients and UDP Servers", Work in Progress, Internet-Draft, draft-ietf-netconf-udp-client-server-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-client-server-05>.

Acknowledgements

Contributors

Xubin LIN
China Southern Power Grid
[email protected]

Authors' Addresses

Feifei HU
China Southern Power Grid
Yu HUANG
China Southern Power Grid
Lei YAN
Huawei Technologies