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 | |||
| Additional resources | |||
| 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]