| 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
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.
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 (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 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.
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.
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.
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.
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].
This document uses the terms defined in[I-D.ietf-sacm-terminology].
A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows:
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.
module: infrastructure-layer-baseline
+--rw infrastructure-layer-baseline
+--rw integrity-measurement
| . . . . . .
+--rw cryptography-security
| . . . . . .
+--rw key-management
| . . . . . .
+--rw certificate-management
. . . . . .
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
+--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
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 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
. . . . . .
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 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
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.
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
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.
submodule: hash-function
+--ro hash-function
+--ro support-algorithm* identityref
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
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
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
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
. . . . . .
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
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
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
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
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.
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
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
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
. . . . . .
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
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
TBD.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
TBD.
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [I-D.ietf-netconf-ssh-client-server] | Watsen, K. and G. Wu, "YANG Groupings for SSH Clients and SSH Servers", Internet-Draft draft-ietf-netconf-ssh-client-server-05, October 2017. |
| [I-D.ietf-netconf-tls-client-server] | Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and TLS Servers", Internet-Draft draft-ietf-netconf-tls-client-server-05, 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", Internet-Draft draft-ietf-sacm-terminology-14, December 2017. |
| [I-D.tran-ipsecme-yang] | Tran, K., Wang, H., Nagaraj, V. and X. Chen, "Yang Data Model for Internet Protocol Security (IPsec)", Internet-Draft draft-tran-ipsecme-yang-00, 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", Internet-Draft draft-xia-sacm-nid-dp-security-baseline-00, September 2017. |