<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-dong-sacm-nid-infra-security-baseline-01"
     ipr="trust200902">
  <front>
    <title abbrev="Network Device Infra. Layer Sec. Baseline">The Data Model
    of Network Infrastructure Device Infrastructure Layer Security
    Baseline</title>

    <author fullname="Yue Dong" initials="Y." surname="Dong">
      <organization>Huawei</organization>

      <address>
        <email>dongyue6@huawei.com</email>
      </address>
    </author>

    <author fullname="Liang Xia" initials="L." surname="Xia">
      <organization>Huawei</organization>

      <address>
        <email>frank.xialiang@huawei.com</email>
      </address>
    </author>

    <date day="25" month="May" year="2018"/>

    <abstract>
      <t>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
      covers the security functions to secure the device itself, and the
      fundamental security capabilities provided by the device to the upper
      layer applications. In this specific document, the integrity
      measurement, cryptography algorithms, key management, and certificate
      management are sorted out to generate the data model.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Network devices such as switches, routers, and firewalls are the
      fundamental elements that a network is composed of. The vulnerabilities
      of a network device are always exploited by attackers to start up
      eavesdropping, spoofing, and man-in-middle attacks etc. Hence it is
      significant to assess the security postures for identifying the possible
      threats and vulnerabilities of a network device in anytime. The SACM
      working group is aim to provide such a mechanism to acquire the posture
      information, which including the security related configuration and
      status attributes, on the target devices and evaluate their security
      postures by comparing with the pre-defined benchmarking criteria.
      Furthermore, the evaluation results are able to be the guidance to
      enforce the corresponding security hardening measurement on the devices
      under assessment. But this hardening process is out of scope of this
      draft.</t>

      <t>This draft and each of the companion document define a subset of
      posture information that have to be collected for the assessment purpose
      mentioned above. This entire set of posture information is so called
      security baseline of a network device that is proposed in the companion
      draft [I-D.draft-xia-sacm-dp-security-profile]. The proposed security
      baseline is presented in the fashion of yang data model. And the
      security baseline yang data model can be requested or subscribed by a
      collector agent such as a yang push client
      [draft-birkholz-sacm-yang-content]. The output of such a collector agent
      is then encapsulated into the SACM content and statement elements
      [draft-ietf-sacm-information-mdoel] and published to other SACM
      components (e.g. repository and evaluator)
      [draft-mandm-sacm-architecture-01]. Please note that document is only
      focus on the yang data model of security baseline, the messaging
      mechanisms is out of scope of this document. They are specified in other
      documents.</t>

      <section title="Infrastructure layer security baseline">
        <t>In general, the entire security baseline of a network device is
        divided into three layers, namely the application layer, the network
        layer, and the infrastructure layer. This document focus on the data
        model on infrastructure layer. The infrastructure layer security
        baseline herein refers to the configuration and status attributes of
        security functions that secure the device itself, and the fundamental
        security capabilities provided by the device to the upper layer
        applications. More specifically, the essential configurable and key
        status attributes of the following function/capability modules are
        sorted out to generate the infrastructure layer security baseline data
        model.<list style="symbols">
            <t>Integrity measurement: the integrity measurement herein refers
            to the functions such as trust computing to protect the device
            against the replacement and/or tampering attacks. For example, the
            trust boot and/or secure boot provide the integrity validation
            service for the kernel and early stage executable code (bios and
            bootloader) in bootstrapping phases, and the digital signature
            protect the upper layer software applications against the
            tampering attacks in software updating phases.</t>

            <t>Cryptography algorithms: the cryptographic algorithms are the
            most important capabilities that the device provides to the upper
            layer security applications. For example, the symmetric (e.g. DES,
            AES) and asymmetric (eg. RSA, ECC) cryptographic algorithms can be
            used for sensitive data encryption, and peers authentication. And
            the key derivation function (KDF) can be used for secret key
            generation and passcode storage.</t>

            <t>Key management: the cryptographic key (pair) and its associated
            algorithm provide various security features for network devices.
            How we manage the key (pair) provisioned in a network device is a
            critical issue. The key management covers the attributes to show
            how the key (pair) is managed in the key&rsquo;s lifecycle (e.g.
            from generation to destroy).</t>

            <t>Certificate management: the certificates are normally provided
            by the device for authentication purpose. The certificate
            management refers to how the certificates and the certificates
            revocation list (CRL) is requested, updated, and validated in the
            device.</t>
          </list></t>

        <t>The practical security baseline of a network device depends on the
        device type, the supported features, the 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 only used to benchmark the most widely deployed
        security related functions and capabilities. And we would like it to
        be an extensible model so that more attributes are able to be added as
        per the practical use case scenario.</t>
      </section>
    </section>

    <section title="Terminology">
      <section title="Key Words">
        <t>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].</t>
      </section>

      <section title="Definition of Terms">
        <t>This document uses the terms defined in<xref
        target="I-D.ietf-sacm-terminology"/>.</t>
      </section>
    </section>

    <section title="Tree Diagrams">
      <t>A simplified graphical representation of the data model is used in
      this document. The meaning of the symbols in these diagrams is as
      follows:<list style="symbols">
          <t>Brackets "[" and "]" enclose list keys.</t>

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

          <t>Symbols after data node names: "?" means an optional node and "*"
          denotes a "list" and "leaf-list".</t>

          <t>Parentheses enclose choice and case nodes, and case nodes are
          also marked with a colon (":").</t>

          <t>Ellipsis ("...") stands for contents of subtrees that are not
          shown.</t>
        </list></t>
    </section>

    <section title="Data Model Structure">
      <t>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.</t>

      <figure>
        <artwork>  module: infrastructure-layer-baseline
      +--rw infrastructure-layer-baseline
         +--rw integrity-measurement
         |  . . . . . .
         +--rw cryptography-algorithms
         |  . . . . . .
         +--rw key-management
         |  . . . . . .
         +--rw certificate-management
            . . . . . .
</artwork>
      </figure>

      <section title="Integrity measurement">
        <t>The purpose of integrity measurement is to prevent 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. Trusted boot and secure boot are
        the two widely used techniques for protecting the device
        bootstrapping. The read-only root of trust (RoT) should be always
        stored in a SoC or TPM chip. 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 force crack them in a short period of time. Moreover,
        the public key used for verifying 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.</t>

        <figure>
          <artwork>  module: integrity-measurement
      +--rw integrity-measurement
         +--rw bootstrapping
         |  +--rw trust-boot
         |  |  +--ro tmp-version              string
         |  |  +--rw tpm-enable               boolean
         |  |  +---u hash-function
         |  |  +--rw pcr-record*  [pcr-number]
         |  |     +--ro pcr-number            unit8
         |  |     +--ro measurement-item      enumeration
         |  |     +--ro pcr-value             string
         |  |     +--ro pcr-benchmark-value   string
         |  |     +--ro verify-result         boolean
         |  +--rw secure-boot
         |     +--ro soc-model                string
         |     +--ro measurement-item*        enumeration
         |     +---u hash-function
         |     +---u signature-algorithm
         |     +--ro verification-public-key
         |        +--ro key-name              string
         |        +--ro key-length            unit16
         |        +--ro key-store-medium      enumeration
         +--rw software-update
            +---u hash-function
            +---u signature-algorithm
            +--ro verification-public-key
               +--ro key-name                 string
               +--ro key-length               unit16
               +--ro key-store-medium         enumeration
      </artwork>
        </figure>
      </section>

      <section title="Cryptography security">
        <t>Almost all the security features of communication network are built
        on the basis of modern cryptography. For example, the cryptographic
        algorithms are usually used to perform transmission data encryption
        and peers authentication. However, as the computing capability of the
        present computing system is getting faster and faster, more and more
        cryptographic algorithms can be brute force cracked in a short period
        of time. Therefore the algorithm has to be selected appropriately for
        different use case scenarios. And the configuration parameters must be
        set within an appropriate range so that the used algorithm is strong
        enough.</t>

        <t>As a fundamental capabilities provided by the device, the practical
        configurations of each supported cryptographic algorithm varies as per
        the upper layer application that employs the algorithm. This section
        organizes the algorithms and their configuration parameters into
        groupings so that the upper layer applications can reference/reuse
        them appropriately.</t>

        <t>In general, this section covers the following cryptographic
        algorithm groupings: <list style="symbols">
            <t>Symmetric algorithms and their configurable parameters.</t>

            <t>Asymmetric algorithms and their configurable parameters.</t>

            <t>Hash functions.</t>

            <t>Message authentication code (MAC) methods and their
            configurable parameters.</t>

            <t>Key derivation functions (KDF) and their configurable
            parameters.</t>
          </list></t>

        <t>All the groupings enable the collection of the specific algorithms
        and their parameters on a case-by-case basis.</t>

        <section title="Symmetrical cryptography">
          <t>The symmetric algorithms are typically used for providing data
          confidential service. The encryption and decryption process of
          symmetrical algorithms make use of two identical keys. And, most of
          the symmetrical algorithms are typically belong to either block
          ciphers or stream ciphers.</t>

          <t>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,
          including cipher block chaining (CBC) mode, cipher feedback (CFB)
          mode, counter mode (CRT), 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 length
          of a plaintext block for most block cipher working mode. But for CRT
          and GCM, the length of IV is optional.</t>

          <t>Stream cipher: unlike block cipher, which encrypt a single
          plaintext block at one time, stream-cipher encrypt every bit of a
          plaintext separately. The stream cipher algorithms also use IV to
          increase the randomness of the original plaintext.</t>

          <figure>
            <artwork>    grouping: symmetric-cryptosystem
          +--rw (algorithm-type)
             +--:(stream-cipher)
             |  +--rw algorithm         identityref
             |  +--rw iv-length         unit16
             |  +--rw iv-randomness     decimal64
             +--:(block-cipher)
                +--rw algorithm         identityref
                +--rw operation-mode    identityref
                +--rw padding-method    identityref
                +--rw iv-length         unit16
                +--rw iv-randomness     decimal64
</artwork>
          </figure>
        </section>

        <section title="Asymmetrical cryptography">
          <t>The asymmetric cryptography is also called public key
          cryptography. In contrast to the symmetric one, asymmetric
          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 other
          key in the key pairs is theoretically public to everyone. The
          asymmetric cryptography algorithms are not only able to provide data
          encryption, but also provide authentication and/or integrity
          protection services (e.g. digital signature).</t>

          <t>Asymmetric 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 recover the
          original plaintext if the public exponent is too small. Hence 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.</t>

          <figure>
            <artwork>  grouping: encryption-algorithm
        +--rw encryption-algorithm
           +--rw rsa-attributes
              +--rw algorithm              identityref
              +--rw padding-method         identityref
              +--rw public-key
                 +--rw public-exponent     unit32
                 +--rw modulo-value        unit32
</artwork>
          </figure>

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

          <figure>
            <artwork>  grouping: signature-algorithms
        +--rw (asymmetric-algorithms)
           +--:(rsa)
           |  +--rw algorithm                identityref
           |  +--rw padding-method           identityref
           |  +--rw public-key
           |     +--rw public-exponent       unit32
           |     +--rw modulo-value          unit32
           +--:(dsa)
           |  +--rw temporary-key
           |  |  +--rw key-length            unit16 
           |  |  +--rw randomness            decimal64
           |  +--rw prime-number
           |     +--rw prime-modulo          unit32
           |     +--rw prime-order           unit32
           +--:(ecdsa)
              +--rw temporary-key
              |  +--rw key-length            unit16
              |  +--rw randomness            decimal64
              +---u hash-function
              +--rw prime-modulo             unit32
              +--rw prime-order              unit32
              +--rw ec-parameters
                 +--rw coefficient-a         unit16
                 +--rw coefficient-b         unit16
</artwork>
          </figure>

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

          <figure>
            <artwork>   grouping: key-exchange
         +--rw (key-exchange)
            +--:(dh)
            |  +--rw dh-handshake
            |     +--rw prime-number-length    unit32
            |     +--rw public-integer-length  unit32
            +--:(ecdh)
               +--rw ecdh-handshake
                  +--rw prime-modulo           unit32
                  +--rw ec-parameters
                  |  +--rw coefficient-a       unit16
                  |  +--rw coefficient-b       unit16
                  +--rw primitive-elements
                     +--rw coordinate-x        unit16
                     +--rw coordinate-y        unit16
</artwork>
          </figure>
        </section>

        <section title="Hash function">
          <t>Hash functions are normally 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 function is widely used in digital signature,
          message authentication code, password hash storage, and etc.</t>

          <figure>
            <artwork>  grouping: hash-function
         +--rw hash-function
            +--rw algorithm             identityref
            +--rw padding-method        identityref
            +--ro digest-length         unit16           
</artwork>
          </figure>
        </section>

        <section title="Message authentication code">
          <t>Similar to digital signature, message authentication code (MAC)
          is another method to provide integrity protection service. MAC
          applies hash function or block cipher algorithms on the message
          plaintext coupled with a pre-shared session key. It must be noted
          that, it is unsafe if simply extend the message with the session
          key.</t>

          <figure>
            <artwork>  grouping: message-authentication-code
         +--rw (message-authentication-code)
            +--: (hmac)
            |  +--rw message-structure    enumeration
            |  |    {prefix|postfix|hmac structure}
            |  +---u hash-function               
            |  +--rw session-key
            |     +--rw key-length        unit16
            |     +--rw randomness        decimal64
            +--: (cmac)
               +--rw block-cipher-algorithm      identityref
               +--rw block-length                unit16
               +--rw iv-length                   unit16
               +--rw randomness                  decimal64  
</artwork>
          </figure>
        </section>

        <section title="Key derivation function">
          <t>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.</t>

          <figure>
            <artwork>  grouping: key-derivation-function
         +--rw (algorithm)
            +--:(pbkdf2)
            |  +---u hash-function
            |  +--rw iteration                unit16
            |  +--rw derived-key-length       unit16
            |  +--rw code-length              unit16
            |  +--rw salt-attributes
            |     +--rw salt-length           unit16
            |     +--rw randomness            decimal64
            +--:(scrypt)
               +--rw code-length              unit16
               +--rw cpu-memory-usage         unit16     
               +--rw block-size               unit8            
               +--rw parallelization          unit8            
               +--rw derived-key-length       unit16
               +--rw salt-attributes
                  +--rw salt-length           unit16
                  +--rw randomness            decimal64
</artwork>
          </figure>
        </section>
      </section>

      <section title="Key management">
        <t>Cryptographic key plays the most important role in a cryptographic
        system. . If the key is disclosed or tampered, the corresponding
        service is not reliable any more. Hence the network device must
        provide the confidentiality and integrity protection for a key in its
        entire lifecycle. This section contains a list of key (pair) and their
        configuration/status parameters corresponding to different lifecycle
        phases. Each of the key (pair) is used in a specific use case.</t>

        <figure>
          <artwork>  module: key-management
      +--rw key-management* [key-name]
         +--rw key-name             string
         +--rw key-length*          unit16          
         +--rw lifetime             unit32
         +--rw key-type             enumeration 
         +--rw num-of-keys          unit8 
         +--rw key-generation
         | . . . . . .
         +--rw key-distribution
         | . . . . . .
         +--rw key-store
         | . . . . . .
         +--rw key-backup
         | . . . . . .
         +--rw key-update
         | . . . . . .
         +--rw key-destroy
           . . . . . .
</artwork>
        </figure>

        <section title="Key generation">
          <t>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 is unpredicted. 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 (e.g. 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.</t>

          <figure>
            <artwork>  submodule: key-generation
         +--rw key-generation
            +--: (random-number-generator)
            |  +--rw key-randomness           decimal64
            +--: (key-derivation-function)
            |  +---u key-derivation-function
            +--: (key-exchange)
               +--rw cert-name                 string
               +---u key-exchange  
</artwork>
          </figure>
        </section>

        <section title="Key distribution">
          <t>Key distribution aims to send the generated keys to authorized
          entities in a secure fashion. The confidentiality and integrity
          issues of the key in distribution are usually addressed by using
          either a secure transport protocol or digital envelop. <xref
          target="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.</t>

          <figure>
            <artwork>  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)
                  +---u symmetric-algorithm
                  +--rw encryption-key-name     string
                  +--rw encryption-key-length   unit16
</artwork>
          </figure>
        </section>

        <section title="Key store">
          <t>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.</t>

          <figure>
            <artwork>  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
</artwork>
          </figure>
        </section>

        <section title="Key update">
          <t>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.</t>

          <figure>
            <artwork>  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-enable    boolean
               +--: (auto)
                  +--rw auto-enble       boolean
                  +--rw update-period    unit8
</artwork>
          </figure>
        </section>

        <section title="Key backup">
          <t>The loss of keys will lead to data loss. Therefore, according to
          the different use case scenarios, a key (pair) may need to backup.
          It is better to divide the key into several parts and store them
          into different storage devices.</t>

          <figure>
            <artwork>  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
</artwork>
          </figure>
        </section>

        <section title="Key destroy">
          <t>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.</t>

          <figure>
            <artwork>  submodule: key-destory
         +--rw key-destory
            +--rw method    {one|zerod|random number} enumeration
            +--rw number-of-times         unit8

</artwork>
          </figure>
        </section>
      </section>

      <section title="Cert management">
        <t>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 contain their entity
        information and public keys from certification authority (CA) in
        advance. The connection will be established only if the certificates
        are verified.</t>

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

        <figure>
          <artwork>  module: cert-management
      +--rw cert-management
         +--rw cert-management
         | . . . . . . 
         +--rw crl-management
           . . . . . .
</artwork>
        </figure>

        <section title="Cert management">
          <t>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.</t>

          <figure>
            <artwork>  module: cert-management
      +--rw cert-management*  [cert-name]
         +--rw cert-name                         string
         +--ro version                           string 
         +--ro serial-number                     string
         +--ro signature-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              unit16
         |  +--ro exponent                       unit32
         +--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  unit8
</artwork>
          </figure>

          <figure>
            <artwork>  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
</artwork>
          </figure>
        </section>

        <section title="CRL management">
          <t>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.</t>

          <figure>
            <artwork>  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              unit32
               |  +--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   
</artwork>
          </figure>
        </section>
      </section>
    </section>

    <section title="Infrastructure Layer YANG Module">
      <t>This section shows a fraction of the infrastructure layer security
      baseline YANG modules.</t>

      <figure>
        <artwork>module ietf-integrity-measurement{
  yang-version 1.1;

  namespace &ldquo;urn:ietf:params:xml:ns:yang:ietf-integrity-measurement&rdquo;;
  prefix "im";

  import ietf-yang-types{
    prefix yang;
    reference
      "RFC6991: Common Yang Data Types";
  }
  
  organization
    "Huawei Technologies";

  contact
    "Yue Dong: dongyue6@huawei.com"
    "Liang Xia: Frank.xialiang@huawei.com"

  description
    "This module defines the configuration and status parameters of the 
    functions that provide the integrity services in the bootstrapping 
    and software updating phases.";

  identity hash-algorithms {
    description
      "base identities of hash algorithms options";
  }  
  
  identity md5 {
    base hash-algorithms;
    description
      "The MD5 algorithm";
  }
  
  identity sha1 {
    base hash-algorithms;
    description 
      "The SHA-1 algorithm";
    reference
      "RFC3174: US Secure Hash Algorithm 1 (SHA1).";
  }
  
  identity sha224 {
    base hash-algorithms;
    description 
      "The SHA-224 algorithm.";
    reference 
      "RFC6234: US Secure Hash Algorithms (SHA and SHA based HMAC and 
      HKDF).";
  }
  
  identity sha256 {
    base hash-algorithms;
    description 
      "The SHA-256 algorithm.";
    reference 
      "RFC6234: US Secure Hash Algorithms (SHA and SHA based HMAC and 
      HKDF).";
  }
  
  identity sha384 {
    base hash-algorithms;
    description
      "The SHA-384 algorithm.";
    reference 
      "RFC6234: US Secure Hash Algorithms (SHA and SHA based HMAC and 
      HKDF).";
  }
  
  identity sha512 {
    base hash-algorithm;
    description
      "The SHA-512 algorithm.";
    reference 
      "RFC6234: US Secure Hash Algorithms (SHA and SHA based HMAC and 
      HKDF).";
  }
  
  identity rsa-algorithms {
    description
      "rsa algorithms with different key length";
  }
  
  identity rsa1024 {
    base rsa-algorithms;
    description
      "The RSA algorithm using a 1024 bit key";
    reference
      "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 
      Cryptography Specifications 2.1"
  }
  
  identity rsa2048 {
    base rsa-algorithms;
    description
      "The RSA algorithm using a 2048 bit key";
    reference
      "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 
      Cryptography Specifications 2.1"
  }
  
  identity rsa3072 {
    base rsa-algorithms;
    description
      "The RSA algorithm using a 3072 bit key";
    reference
      "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 
      Cryptography Specifications 2.1"
  }
  
  identity rsa4096 {
    base rsa-algorithms;
    description
      "The RSA algorithm using a 4096 bit key";
    reference
      "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 
      Cryptography Specifications 2.1"
  }
  
  identity rsa7680 {
    base rsa-algorithms;
    description
      "The RSA algorithm using a 7680 bit key";
    reference
      "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 
      Cryptography Specifications 2.1"
  }
  
  identity rsa15360 {
    base rsa-algorithms;
    description
      "The RSA algorithm using a 15360 bit key";
    reference
      "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 
      Cryptography Specifications 2.1"
  }
  
  identity rsa-padding {
    description
      "The identities of padding methods for rsa.";
  }
  
  identity oaep {
    base rsa-padding;
    description
      "The OAEP padding method for RSA.";
  }
  
  identity pss {
    base rsa-padding;
    description
      "The PSS padding method for RSA.";
  }
  
  container integrity-measurement {
    container bootstrapping {
      container trust-boot {
        leaf tpm-version {
          type string;
          description
            "version of the tpm chip";
        }

        leaf tpm-enable {
          type boolean;
          description
            &ldquo;switch of the trust boot function&rdquo;;
        }

        uses hash-function 

        list pcr-record {
          key "pcr-number";
  
          leaf pcr-number {
            type unit8;
            description 
              "Number of pcr register";
          }

          leaf measurement-item{
            type enumeration {
              enum bios;
              enum bootloader;
              enum kernel;
              enum patch;
            }
            description
              "This property shows which item is measured and recored by 
              the pcr";
          }

          leaf pcr-value {
            type string;
            description 
              "The practical measurement value";
          }

          leaf pcr-benchmark-value {
            type string;
            description
              "The pre-defined benchmark criterion";
          }

          leaf verify-result {
            type boolean;
            description 
              "The benchmark result for each pcr recorded value";
          }
        }
      }

      container secure-boot {
        leaf soc-model {
          type string;
          description 
            "Model of the used SoC";
        }
    
        leaf-list measurement-items {
          type enumeration {
            enum bios;
            enum bootloader;
            enum kernel;
            enum patch;
          }
          description
            "List of the items to be measured in the secure boot 
            process";
        }  
    
        uses hash-function 
    
        uses signature-algorithm 
    
        container verification-pub-key {
          leaf key-name {
            type string;
            description
              "Name of the public key for verfication";
          }
      
          leaf key-length {
            type unit16;
            description
              "Length of the public key"
          }
      
          leaf store-medium {
            type enumeration {
              enum tmp;
              enum soc;
              enum hdd;
              enum hsm;
            }
            description 
              "This property describes where the public key stores"
          }
        }
      }
    }
  
    container software-update {
      uses hash-function; 
  
      uses signature-algorithm; 
  
      container verification-pub-key {
        leaf key-name {
          type string;
          description
            "Name of the public key for verification";
        }
    
        leaf key-length {
          type unit16;
          description 
            "Length of the public key";
        }
    
        leaf store-medium {
          type enumeration {
            enum tpm;
            enum soc;
            enum hdd;
            enum hsm;
          }
          description 
            "This property decribes where the pub key stores"
        }
      }
    }
  }

  grouping hash-function {
    description
      "A group of Hash functions and their parameters";
    
    leaf algorithm {
      type identityref {
        base "hash-algorithm";
      }
      description
        "Identities of the used Hash algorithm";
    }
  
    leaf padding-method {
      type identityref;
      description
        ""
    }
  
    leaf digest-length {
      type unit16;
      description
        "The length of the Hash output";
    }
  }

  grouping signature-algorithms {
    "A group of algorithms and their configurable parameters for digital 
    signature";
  
    choice algorithm-type {
      case rsa {
        leaf algorithm {
          type identityref {
            base "rsa-algorithm";
          }
          description
            "identities of the rsa algorithms for digital signature";
        }
      
        leaf padding-method {
          type identityref;
          description 
            "identities of padding method for the used algorithm"
        }
      
        container pub-key {
          leaf public-exponent {
            type unit32;
            description
              "value of public exponent";
          }
        
          leaf modulo-value {
            type unit32;
            description 
              "value of modulo";
          }
        }
      }
    
      case dsa {
        container tempory-key {
          leaf key-length {
            type unit16;
            description 
              "The length of the tempory key.";
          }
          
          leaf randomness {
            type decimal64;
            description
              "This value represents the randomness of this key.";
          }
        }
      
        container prime-number {
          leaf prime-modulo {
            type unit32;
            description 
              "value of modulo";
          }
        
          leaf prime-order {
            type unit32;
            description 
              "value of prime number";
          }
        }
      }
    
      case ecdsa {
        containter tempory-key {
          leaf key-length {
            type unit16;
            description 
              "The length of the tempory key that is generated by a 
              random number generator.";
          }
          
          leaf randomness {
            type decimal64
            description
              "This value represents the randomness of the key. It is 
              generated by a tool like sts 2.1.";
          }
        }
      
        leaf prime-modulo {
          type unit32;
          description
            "value of modulo";
        }
      
        leaf prime-order {
          type unit32;
          description
            "value of order";
        }
      
        uses hash-function
      
        container ec-parameter {
          leaf coefficient-a {
            type unit8;
            description
              "constant coefficient of the selected elliptic curve.";
          }
        
          leaf coefficient-b {
            type unit8;
            description 
              "constant coefficient of the selected elliptic curve.";
          }
        }
      }
    }
  }
}</artwork>
      </figure>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.draft-ietf-sacm-terminology-14'?>

      <?rfc include='reference.I-D.draft-ietf-netconf-tls-client-server-05'?>

      <?rfc include='reference.I-D.draft-tran-ipsecme-yang-00'?>

      <?rfc include='reference.I-D.draft-ietf-netconf-ssh-client-server-05'?>

      <?rfc include='reference.I-D.draft-xia-sacm-nid-dp-security-baseline-01'?>

      <?rfc include='reference.I-D.draft-ietf-sacm-information-model-10'?>

      <?rfc include='reference.I-D.draft-mandm-sacm-architecture-01'?>
    </references>
  </back>
</rfc>
