Skip to main content

The Data Model of Network Infrastructure Device Infrastructure Layer Security Baseline
draft-dong-sacm-nid-infra-security-baseline-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Yue Dong , Liang Xia
Last updated 2018-01-15
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dong-sacm-nid-infra-security-baseline-00
Network Working Group                                            Y. Dong
Internet-Draft                                                    L. Xia
Intended status: Standards Track                                  Huawei
Expires: July 20, 2018                                  January 16, 2018

  The Data Model of Network Infrastructure Device Infrastructure Layer
                           Security Baseline
             draft-dong-sacm-nid-infra-security-baseline-00

Abstract

   This document is one of the companion documents which describes the
   infrastructure layer security baseline YANG output for network
   infrastructure devices.  The infrastructure layer security baseline
   includes all the fundamental security capabilities/functions about
   the device itself, which may also be provided by the device to the
   upper layer applications as a secure environment.  In this particular
   document, the integrity measurement, cryptography security, secure
   key management, and secure certificate management are summarized to
   generate the data model.

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 July 20, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Dong & Xia                Expires July 20, 2018                 [Page 1]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Objective . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Data model overview . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Key Words . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Definition of Terms . . . . . . . . . . . . . . . . . . .   4
   3.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Data Model Structure  . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Integrity measurement . . . . . . . . . . . . . . . . . .   5
     4.2.  Cryptography security . . . . . . . . . . . . . . . . . .   6
       4.2.1.  Symmetrical cryptography  . . . . . . . . . . . . . .   7
       4.2.2.  Asymmetrical cryptography . . . . . . . . . . . . . .   8
       4.2.3.  Hash function . . . . . . . . . . . . . . . . . . . .   9
       4.2.4.  Message authentication code . . . . . . . . . . . . .  10
       4.2.5.  Key derivation function . . . . . . . . . . . . . . .  10
       4.2.6.  Random number generator . . . . . . . . . . . . . . .  11
     4.3.  Key management  . . . . . . . . . . . . . . . . . . . . .  11
       4.3.1.  Key generation  . . . . . . . . . . . . . . . . . . .  12
       4.3.2.  Key distribution  . . . . . . . . . . . . . . . . . .  12
       4.3.3.  Key store . . . . . . . . . . . . . . . . . . . . . .  13
       4.3.4.  Key update  . . . . . . . . . . . . . . . . . . . . .  13
       4.3.5.  Key backup  . . . . . . . . . . . . . . . . . . . . .  13
       4.3.6.  Key destroy . . . . . . . . . . . . . . . . . . . . .  14
     4.4.  Cert management . . . . . . . . . . . . . . . . . . . . .  14
       4.4.1.  Cert management . . . . . . . . . . . . . . . . . . .  15
       4.4.2.  CRL management  . . . . . . . . . . . . . . . . . . .  16
   5.  Infrastructure Layer Yang Module  . . . . . . . . . . . . . .  16
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

Dong & Xia                Expires July 20, 2018                 [Page 2]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

1.1.  Objective

   Network devices such as switches, routers, and firewalls are the
   fundamental elements that a network is composed of.  The
   vulnerabilities of them are always exploited by attackers to start up
   eavesdropping, spoofing, and man-in-middle attacks etc.  In order to
   guarantee the security of the entire network, each individual network
   device in the network has to meet its minimal security requirements
   according to its intended functions.  These minimal security
   requirements are so called security baseline of a network device that
   is proposed in the companion draft [I-D.draft-xia-sacm-dp-security-
   profile].  In detail, the security baseline refers to the basic and
   compulsory security capabilities, configurations and statuses that
   can be collected and evaluated anytime to identify the possible
   threats and vulnerabilities in order to enforce the corresponding
   security hardening measurement on device itself.  In other words, the
   security baseline is able to be set and used by the benchmark policy
   to evaluate security posture of an individual network device, then
   fix/enhance it.

   In general, the security baseline of a network device can be
   classified into three layers, namely the application layer, the
   network layer, and the infrastructure layer.  This document defines a
   data model of the information (i.e. attributes/parameters) that have
   to be collected from the target device and then be used for comparing
   with the benchmark policies to assess the device infrastructure layer
   security posture.

1.2.  Data model overview

   The infrastructure layer security baseline is defined as all the
   fundamental security functions about the device itself, which may
   also be provided by the device to the upper layer applications as a
   secure environment.  In this document, the essential attributes and
   configurable parameters and key status of the following function
   modules are sorted out to generate the data model that can be
   consumed by SACM collector and evaluator to evaluate whether the
   device meet the baseline or not.

   o  Integrity measurement

   o  Cryptography security

   o  Secure key management

   o  Secure certificate management

Dong & Xia                Expires July 20, 2018                 [Page 3]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

   The actual security baseline of a certain network device relies on
   device type, supported features, requirements of operators and
   enterprises, and the role it plays exactly in the network.  Owing to
   such a number of variance, it is impossible to design a comprehensive
   and unified data model for all devices.  Thus the proposed data model
   in this document is used to benchmark the most widely deployed
   baseline.  More points can be added into the data model in the
   future.

2.  Terminology

2.1.  Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.2.  Definition of Terms

   This document uses the terms defined in[I-D.ietf-sacm-terminology].

3.  Tree Diagrams

   A simplified graphical representation of the data model is used in
   this document.  The meaning of the symbols in these diagrams is as
   follows:

   o  Brackets "[" and "]" enclose list keys.

   o  Abbreviations before data node names: "rw" means configuration
      (read-write) and "ro" state data (read-only).

   o  Symbols after data node names: "?" means an optional node and "*"
      denotes a "list" and "leaf-list".

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

4.  Data Model Structure

   As mentioned above, the top-level structure of the data model is
   shown in the following figure.  There are four subtrees in the tree
   diagram.  Each of the following sub-sections specifies the detail of
   an individual subtree.

Dong & Xia                Expires July 20, 2018                 [Page 4]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

     module: infrastructure-layer-baseline
         +--rw infrastructure-layer-baseline
            +--rw integrity-measurement
            |  . . . . . .
            +--rw cryptography-security
            |  . . . . . .
            +--rw key-management
            |  . . . . . .
            +--rw certificate-management
               . . . . . .

4.1.  Integrity measurement

   The purpose of integrity measurement is to protect the upper layer
   software applications, kernel, and early stage executable code (e.g.
   BIOS and bootloader) from replacement and/or tampering in
   bootstrapping and updating phases.  Trusetd boot and secure boot are
   usually used to protect the deivce in bootstrapping.  The read-only
   root of trust should be always stored in a SoC or TPM chip.  In
   addition, the chip is also able to provide key management service and
   cryptography engine.  For software updating, digital signature has
   been demonstrated as a powerful tool to provide the integrity
   protection service.  In using digital signature, the employed hash
   function and signature algorithm must be strong enough so that
   attackers cannot crack them.  Moreover, the public key used for
   verfying the signature should be stored properly.  For example, it
   can be wrapped in a certificate of the software vendor or stored in
   the read-only SoC or TPM.

     module: integrity-measurement
         +--rw integrity-measurement
            +--ro root-key-store
            |  +--ro endorsement-key
            |  |  +--ro store-medium              enumeration
            |  |  +--ro key-length                int
            |  +--ro storage-root-key
            |  |  +--ro store-medium              enumeration
            |  |  +--ro key-length                int
            |  +--ro other-keys*   [key-name]
            |     +--ro key-name                  string
            |     +--ro key-id                    int
            |     +--ro key-generation            enumeration
            |     +--ro key-usage                 enumeration
            |     +--ro key-store                 enumeration
            |     +--ro associate-kek-name        string
            |     +--ro key-lifetime
            |        +--ro start-time         yang-type:date-and-time
            |        +--ro end-time           yang-type:date-and-time

Dong & Xia                Expires July 20, 2018                 [Page 5]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

            +--ro cryptography-system
            |  +--ro hash-function*               identityref
            |  +--ro asymmetrical-encryption-algorithm*  identityref
            |  +--ro symmetrical-encryption-algorithm*   identityref
            |  +--ro asymmetrical-signing-algorithm*   identityref
            |  +--ro HMAC*                          identityref
            |  +--ro key-derivation-function*       identityref
            |  +--ro random-number-generator*       identityref
            +--ro trust-measurement
               +--ro bootstrapping-measurement
               |  +--ro crtm-store-medium           enumeration
               |  +--ro measurement-item*           enumeration
               |  +--ro hash-algorithm              identityref
               |  +--ro trust-boot?
               |  |  +--ro tmp-version              string
               |  |  +--ro tpm-verndor              string
               |  |  +--rw tpm-enable               boolean
               |  |  +--rw pcr-record
               |  |     +--ro pcr-number            int
               |  |     +--rw pcr-operation         enumeration
               |  |     +--ro pcr-value             string
               |  |     +--ro pcr-benchmark-value   string
               |  |     +--ro verify-results        boolean
               |  +--ro secure-boot?
               |     +--rw signature-algorithm     identityref
               |     +--ro verification-public-key
               |        +--ro key-name             string
               |        +--ro key-length           int
               |        +--ro key-code             string
               |        +--ro key-store-medium     enumeration
               +--rw software-update
                  +--rw hash-algorithm             identityref
                  +--rw signature-algorithm        identityref
                  +--rw verification-public-key
                     +--ro key-name                string
                     +--ro key-length              int
                     +--ro key-code                string
                     +--ro key-store-medium        enumeration

4.2.  Cryptography security

   Almost all the security features of communication network are built
   on the basis of modern cryptography.  As the computing capability is
   getting faster and faster, more and more cryptographic algorithms can
   be brute force cracked in a short period of time.  In order to ensure
   the security of individual device and the entire network, all the
   network devices in the network must support robust and strong enough

Dong & Xia                Expires July 20, 2018                 [Page 6]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

   cryptographic algorithms for all security applications/services
   running on the device.

   In general, symmetrical cryptography, asymmetrical cryptography, and
   Hash cryptography are the three common used cryptography systems.  As
   per there different usage scenarios, each of the cryptography system
   must follow their own security rules respectively.  The following
   tree diagram shows the top-level layout of the cryptography security
   module.  Apart from the three cryptography systems mentioned above,
   the attributes of message authentication code (MAC), key derivation
   function, and random number generator are also sorted out.

     module: cryptography-security
         +--rw cryptography-security
            +--rw symmetrical-cryptosystem
            | . . . . . .
            +--rw asymmetrical-cryptosystem
            | . . . . . .
            +--rw hash-function
            | . . . . . .
            +--rw message-authentication-code
            | . . . . . .
            +--rw key-derivation-function
            | . . . . . .
            +--rw random-number-generator
              . . . . . .

4.2.1.  Symmetrical cryptography

   An algorithm and its associate key pairs in symmetrical cryptosystem
   provide data confidential service.  The encryption and decryption
   process in the symmetrical cryptosystem make use of two identical
   keys.  Typically, most of the symmetrical algorithms are belong to
   either block ciphers or stream ciphers.

   Block cipher: block cipher divides the plaintext in to a number of
   blocks with a constant bit length.  And the last plaintext block
   should be filled to fit the bit length requirement.  Then each of the
   plaintext blocks is encrypted individually.  However, if a plaintext
   piece repeats several times in a long data stream, it is easier for
   an attacker to guess the original plaintext from the repeated
   ciphertext.  Hence, some other operation modes of block cipher, such
   as cipher block chaining (CBC), cipher feedback (CFB), and Galois
   counter mode (GCM), are proposed to introduce a random bit stream,
   which is named initialization vector (IV), to augment the randomness
   of the original plaintext.  The used random number generator must
   meet the randomness requirement so that the IV value is unpredicted.
   In addition, the bit length of IV should be the same as the bit

Dong & Xia                Expires July 20, 2018                 [Page 7]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

   length of a plaintext block for most block cipher working mode.  But
   for GCM, the length of IV is optional.

     submodule: block-cipher
            +--ro block-cihper
               +--ro support-algorithm*              identityref
               +--ro support-operation-mode*         identityref
               +--ro support-padding-method*         identityref
               +--ro iv-generation*                  identityref
               +--ro gcm-iv-length
                  +--ro max-length                       int
                  +--ro min-length                       int

   Stream cipher: unlike block cipher, which encrypt a single plaintext
   block at one time, stream-cipher every bit of a plaintext separately.
   The stream cipher algorithms must be strong enough in case it is able
   to be cracked in days or even hours.

     submodule: stream-cipher
            +--ro stream-cipher
               +--ro support-algorithm*              identityref

4.2.2.  Asymmetrical cryptography

   The asymmetrical cryptography is also called public key cryptography.
   In contrast to the symmetrical one, asymmetrical cryptography always
   employs a key pair that contains two different keys to deal with the
   encryption and decryption work.  The private key in the key pairs is
   held and used only by the owner.  The public key of the key pairs is
   theoretically able to be used by anybody.  The asymmetrical
   cryptography algorithms provide not only data encryption, but also
   authentication and integrity protection services (i.e. digital
   signature).

   Asymmetrical encryption: RSA is the most commonly used asymmetrical
   encryption algorithm.  In the use of RSA, the smaller the public
   exponent is, the higher efficiency the algorithm has.  In the other
   side, it will be much easier to crack the algorithm and revocer the
   original plaintext if the public exponent is too small.  Hnece it has
   to trade off the value of public exponent.  In addition, the RSA is
   recommend to use optimal asymmetrical encryption padding (OAEP) to
   fill up the original plaintext.

Dong & Xia                Expires July 20, 2018                 [Page 8]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

     submodule: asymmetrical-encryption
            +--ro asymmetrical-encryption
               +--ro support-algorithm*                 identityref
               +--ro rsa-public-exponent-length*        int
               +--ro support-rsa-padding-method*        identiryref
               +--ro public-key* [key-id]
                  +--ro key-name                        string
                  +--ro key-id                          int
                  +--ro key-length                      int
                  +--ro asymmetrical-key-algorithm      identityref
                  +--ro public-key-code                 string

   Digital signature: digital signature is a powerful tool to provide
   integrity protection.  DSA, RSA, and ECDSA are three of the most
   popular signature algorithms.  By using RSA in digital signature, it
   is better to use PSS for padding.  If the data is required to be
   encrypted and signed at the same time, it is suggest to sign the data
   before encrypting.

     submodule: digital-signature
            +--ro digital-signature
               +--ro support-algorithm*                 identityref
               +--ro rsa-padding-method*                identityref
               +--ro public-key* [key-id]
                  +--ro key-name                        string
                  +--ro key-id                          int
                  +--ro key-length                      int
                  +--ro asymmetrical-key-algorithm      identityref
                  +--ro public-key-code                 string

   Key exchange: key exchange is meant to establish key pairs between
   communication peers.  The peers send key material rather than key
   itself to each other.

     submodule: key-exchange
            +--ro key-exchange
               +--ro support-algorithm*                identityref

4.2.3.  Hash function

   Hash functions are always used to perform integrity measurement.  The
   output of a Hash function is a digest with a constant bit length for
   a segment of messages or code.  The digest is unique and unable to be
   reconstructed if the original message/code is tampered.  The Hash
   functions is widely used in digital signature, message authentication
   code, password hash storage, and etc.

Dong & Xia                Expires July 20, 2018                 [Page 9]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

     submodule: hash-function
            +--ro hash-function
               +--ro support-algorithm*             identityref

4.2.4.  Message authentication code

   Similar to digital signature, message authentication code (MAC) is
   another method to provide integrity protection service.  MAC apply
   hash function on the message plaintext coupled with a pre-shared key.
   It must be noted that, it is unsafte if simply extend the message
   with key.

     submodule: message-authentication-code
            +--ro message-authentication-code
               +--ro support-algorithm*          identityref
               +--ro support-key-length*          int
               +--ro support-tag-length*          int

4.2.5.  Key derivation function

   Key derivation function derives one or more keys from a master key or
   entered password.  A salt value is generated by a random number
   generator to introduce the randomness of the derived keys.

   submodule: key-derivation-function
          +--ro support-algorithm*                   identityref
          +--ro pbkdf2-attributes
          |  +--ro support-hash-algorithm*           identityref
          |  +--ro counter
          |  |  +--ro max-counter                    int
          |  |  +--ro min-counter                    int
          |  +--ro salt-attributes
          |  |  +--ro random-number-generator        identityref
          |  |  +--ro support-salt-length*           int
          |  |  +--ro max-salt-value                 int
          |  |  +--ro min-salt-value                 int
          |  +--ro support-derived-key-length*       int
          +--ro scrypt-attributes
             +--ro salt-attributes
             |  +--ro random-number-generator        identityref
             |  +--ro support-salt-length*           int
             |  +--ro max-salt-value                 int
             |  +--ro min-salt-value                 int
             +--ro support-derived-key-length*       int

Dong & Xia                Expires July 20, 2018                [Page 10]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

4.2.6.  Random number generator

   A random number generator is probably used in any cryptography
   systems.  It must ensure the generated random number is unpredicted.
   As per the BSI classification standard, the random number generators
   can be divided into true random and pseudo random divisions.

     submodule: random-number-generator
            +--ro random-number-generator
               +--ro support-method*               identityref
               +--ro support-trng*                 identityref
               +--ro support-prng*                 identityref
               +--ro support-csprng*               identityref

4.3.  Key management

   Cryptographic key plays the most important role in a cryptographic
   system.  It provides several of security functions in communication
   networks.  Secret key protect the data conveyed via an unsecured
   connection.  Another example is that private key can provide
   authentication and signature services.  If the key is disclosed or
   tampered, the services provided by the key is not reliable any more.
   Hence the network device must provide the confidentiality and
   integrity protection for a key in its entire lifecycle.

     module: key-management
         +--rw key-management* [key-name]
            +--rw key-name            string
            +--rw key-id               int
            +--rw key-length           int
            +--rw lifetime             int
            +--rw key-type  {master key|kek|root key}   enumeration
            +--rw key-generation
            | . . . . . .
            +--rw key-distribution
            | . . . . . .
            +--rw key-store
            | . . . . . .
            +--rw key-backup
            | . . . . . .
            +--rw key-update
            | . . . . . .
            +--rw key-destroy
              . . . . . .

Dong & Xia                Expires July 20, 2018                [Page 11]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

4.3.1.  Key generation

   There are three types of commonly used key generation methods.  The
   first method is on the basis of random number generator.  In this
   method, the referenced random number generator has to ensure the
   generated key will not be predicted.  The second key generation
   method is based on the manual entered password.  However, the entered
   password is not meet the randomness requirement.  In this case, a key
   derivation function (eg.  PBKDF2) is applied to derive the key.  The
   last key generation method is key exchange such as Diffie-Hellman
   (DH) protocol.  This kind of method requires the peers to
   authenticate each other before exchange the key material.

     submodule: key-generation
            +--rw key-generation
               +--: (random-number-generator)
               |  +--rw generator-type                identityref
               +--: (key-derivation-function)
               |  +--rw hash-algorithm                identityref
               |  +--rw entered-password              string
               |  +--rw salt-value                    string
               |  +--rw liter-count                   int
               +--: (key-exchange)
                  +--rw key-exchange-protocol         identityref

4.3.2.  Key distribution

   Key distribution aims to send the generated keys to authorized
   entities in secure fashion.  The confidentiality and integrity issues
   of the key in distribution is usually addressed by using either a
   secure transport protocol, such as TLS
   [I-D.ietf-netconf-tls-client-server], IPsec [I-D.draft-tran-ipsecme-
   yang], or SSH [I-D.ietf-netconf-ssh-client-server], or digital
   envelop.

     submodule: key-distribution
            +--rw key-distribution?
               +--rw symmetrical-key
                  +--: (secure-transport-protocol)
                  |  +--rw tls-config
                  |  |   [I-D.ietf-netconf-tls-client-server]
                  |  +--rw ipsec-config
                  |  |   [I-D.draft-tran-ipsecme-yang]
                  |  +--rw ssh-config
                  |  |   [I-D.ietf-netconf-ssh-client-server]
                  +--: (digital-envolop)
                     +--rw encryption-algorithm    identityref
                     +--rw encryption-key-name     string

Dong & Xia                Expires July 20, 2018                [Page 12]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

4.3.3.  Key store

   A typical key management system has three layers.  The master keys
   that consumed by upper layer applications are in the top layer.  The
   key in the middle layer, which is called key encryption key (KEK), is
   used to encrypt the master keys.  And the KEK itself is encrypted by
   the root key which stays in the bottom layer of the three layer key
   management system.

     submodule: key-store
            +--rw key-store
               +--ro store-medium {TPM|HSM|HDD}     enumeration
               +--rw key-component* [component-name]
                  +--rw component-name              string
                  +--ro store-medium                enumeration

4.3.4.  Key update

   Network device must update the key in a reasonable period of time.
   Otherwise the long term used key will attract attackers to crack it.
   The practical update period of a certain key depends on the
   application the key serves and the strength (i.e. bit length) of the
   key itself.

     submodule: key-update
            +--rw key-update
               +--rw next-update-time       yang-type:date-and-time
               +--rw hold-expired-key       boolean
               +--rw update-mode
                  +--: (manual)
                  |  +--rw manual-status  {enable|disable}  boolean
                  +--: (auto)
                     +--rw auto-status {enable|disable}   boolean
                     +--rw update-period       int

4.3.5.  Key backup

   The loss of keys will lead to data loss.  Therefore, according to the
   different use case scenarios, a key may need to backup in case the
   encrypted data is unable to be decrypted when the key is missing.  It
   is better to divide the key into several parts and store them into
   different storage devices.

Dong & Xia                Expires July 20, 2018                [Page 13]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

     submodule: key-backup
            +--rw key-backup?
               +--rw backup-enable         boolean
               +--rw backup-expire-time     yang-type:date-and-time
               +--rw backup-component* [component-name]
                  +--rw component-name       string
                  +--ro backup-medium        enumeration

4.3.6.  Key destroy

   The key and its associated key material must be destroyed when it is
   expired.  Otherwise the expired key will be used by attackers to
   decrypt the data encrypted by this key.  Also, the expired key can be
   used to analysis the cryptosystem.

     submodule: key-destory
            +--rw key-destory?
               +--rw method    {one|zerod|random number} enumeration
               +--rw number-of-times         int

4.4.  Cert management

   The TLS/DTLS and IPsec have been demonstrated as powerful security
   tools to provide data confidentiality and integrity services between
   network elements.  In order to protect the TLS/DTLS or the IPsec
   connection against man-in-middle attack, peers have to authenticate
   from each other before connection establishing.  The pre-shared key
   and the certificate are two of the most widely used methods to
   authenticate peers' identities.  However, it requires to re-configure
   the pre-shared keys on all other endpoints/network elements if an
   additional network device is added in network.  This complicated re-
   configuration process is easy to make errors.  In the other hand,
   certificate is an idea way to extend authentications to a much larger
   scale of network.  Peers request certificates that contains their
   entity information and public keys from certification authority (CA)
   in advance.  The connection will be established only if the
   certificates are verified.

   For a specific network device, such as switch and router, the
   certification service normally includes certificates request and
   updating, certificates validity check.

     module: cert-management
         +--rw cert-management
            +--rw cert-management
            | . . . . . .
            +--rw crl-management
              . . . . . .

Dong & Xia                Expires July 20, 2018                [Page 14]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

4.4.1.  Cert management

   A cert request file that contains the device public key and entity
   information is sent to the CA to apply a certificate.  A CMP session
   is configured to request and update the certificates.  A build-in
   default certificate in the device is used for identity authentication
   for CMP session.  And the certificate must be updated in a reasonable
   period of time via CMP session.

  module: cert-management
      +--rw cert-management*  [cert-name]
         +--rw cert-name                         string
         +--ro version                           int
         +--ro serial-number                     int
         +--ro siganture-algorithm               identityref
         +--ro issuer-name                       string
         +--rw cert-request
         |  +--rw cmp-session-name               string
         +--ro validity
         |  +--ro start-time                     yang-type:date-and-time
         |  +--ro end-time                       yang-type:data-and-time
         +--ro subject-public-key
         |  +--ro public-key-algorithm           identityref
         |  +--ro public-key-length              int
         |  +--ro public-key-code                string
         |  +--ro exponent                       int
         +--rw cert-auto-update
            +--rw cert-name                      string
            +--rw pki-domain-name                string
            +--rw cmp-session-name               string
            +--rw auto-update-enable             boolean
            +--rw trigger-condition
               +--rw validity-percentage-number  int

     grouping: cmp-session-config
           +--rw cmp-session-config*  [session-name]
              +--rw domain-name                     string
              +--rw session-name                    string
              +--rw entity-name                     string
              +--rw key-name                        string
              +--rw ca-server-name                  string
              +--rw default-cert-name               string
              +--rw cmp-server-url                  string

Dong & Xia                Expires July 20, 2018                [Page 15]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

4.4.2.  CRL management

   The certificate revocation list (CRL) contains the invalid/expired
   certificates.  It is equivalent to a blacklist of certificates issued
   by CA.  The validity of a received cert is able to be checked by
   comparing with the CRL.  The CRL need to update from CA by either an
   automatic or manual way.

  submodule: crl-management
         +--rw crl-management
            +--rw cert-validity-check-enable        boolean
            +--rw crl-update
               +--rw previous-update-time         yang-type:date-and-time
               +--rw auto-update
               |  +--rw auto-update-enable         boolean
               |  +--rw update-period              int
               |  +--rw next-update-time           yang-type:date-and-time
               |  +--rw update-method  {http|ldap} enumeration
               +--rw manual-update
                  +--rw manual-update-enable       boolean
                  +--rw update-method  {http|ldap} enumeration

5.  Infrastructure Layer Yang Module

   TBD.

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

7.  Security Considerations

   TBD.

8.  Acknowledgements

   TBD

9.  References

9.1.  Normative References

Dong & Xia                Expires July 20, 2018                [Page 16]
Internet-Draft  Network Device Infra. Layer Sec. Baseline   January 2018

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

9.2.  Informative References

   [I-D.ietf-netconf-ssh-client-server]
              Watsen, K. and G. Wu, "YANG Groupings for SSH Clients and
              SSH Servers", draft-ietf-netconf-ssh-client-server-05
              (work in progress), October 2017.

   [I-D.ietf-netconf-tls-client-server]
              Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and
              TLS Servers", draft-ietf-netconf-tls-client-server-05
              (work in progress), October 2017.

   [I-D.ietf-sacm-terminology]
              Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and
              A. Montville, "Security Automation and Continuous
              Monitoring (SACM) Terminology", draft-ietf-sacm-
              terminology-14 (work in progress), December 2017.

   [I-D.tran-ipsecme-yang]
              Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data
              Model for Internet Protocol Security (IPsec)", draft-tran-
              ipsecme-yang-00 (work in progress), October 2015.

   [I-D.xia-sacm-nid-dp-security-baseline]
              Xia, L. and G. Zheng, "The Data Model of Network
              Infrastructure Device Data Plane Security Baseline",
              draft-xia-sacm-nid-dp-security-baseline-00 (work in
              progress), September 2017.

Authors' Addresses

   Yue Dong
   Huawei

   Email: dongyue6@huawei.com

   Liang Xia
   Huawei

   Email: frank.xialiang@huawei.com

Dong & Xia                Expires July 20, 2018                [Page 17]