idnits 2.17.00 (12 Aug 2021) /tmp/idnits13326/draft-dong-sacm-nid-infra-security-baseline-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 254 has weird spacing: '...k-value stri...' == Line 348 has weird spacing: '...on-mode ide...' == Line 349 has weird spacing: '...-method ide...' == Line 424 has weird spacing: '...-length uni...' == Line 425 has weird spacing: '...-length unit3...' == (8 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 25, 2018) is 1450 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.draft-xia-sacm-dp-security-profile' is mentioned on line 110, but not defined == Missing Reference: 'I-D.draft-tran-ipsecme-yang' is mentioned on line 571, but not defined == Unused Reference: 'I-D.ietf-sacm-information-model' is defined on line 1207, but no explicit reference was found in the text == Unused Reference: 'I-D.mandm-sacm-architecture' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'I-D.tran-ipsecme-yang' is defined on line 1224, but no explicit reference was found in the text == Unused Reference: 'I-D.xia-sacm-nid-dp-security-baseline' is defined on line 1229, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-netconf-ssh-client-server-05 == Outdated reference: A later version (-27) exists of draft-ietf-netconf-tls-client-server-05 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-14 == Outdated reference: A later version (-01) exists of draft-tran-ipsecme-yang-00 == Outdated reference: A later version (-03) exists of draft-xia-sacm-nid-dp-security-baseline-01 Summary: 0 errors (**), 0 flaws (~~), 19 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Dong 3 Internet-Draft L. Xia 4 Intended status: Standards Track Huawei 5 Expires: November 26, 2018 May 25, 2018 7 The Data Model of Network Infrastructure Device Infrastructure Layer 8 Security Baseline 9 draft-dong-sacm-nid-infra-security-baseline-01 11 Abstract 13 This document is one of the companion documents which describes the 14 infrastructure layer security baseline YANG output for network 15 infrastructure devices. The infrastructure layer security baseline 16 covers the security functions to secure the device itself, and the 17 fundamental security capabilities provided by the device to the upper 18 layer applications. In this specific document, the integrity 19 measurement, cryptography algorithms, key management, and certificate 20 management are sorted out to generate the data model. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 26, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Infrastructure layer security baseline . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 61 3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Data Model Structure . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Integrity measurement . . . . . . . . . . . . . . . . . . 5 64 4.2. Cryptography security . . . . . . . . . . . . . . . . . . 6 65 4.2.1. Symmetrical cryptography . . . . . . . . . . . . . . 7 66 4.2.2. Asymmetrical cryptography . . . . . . . . . . . . . . 8 67 4.2.3. Hash function . . . . . . . . . . . . . . . . . . . . 10 68 4.2.4. Message authentication code . . . . . . . . . . . . . 10 69 4.2.5. Key derivation function . . . . . . . . . . . . . . . 11 70 4.3. Key management . . . . . . . . . . . . . . . . . . . . . 11 71 4.3.1. Key generation . . . . . . . . . . . . . . . . . . . 12 72 4.3.2. Key distribution . . . . . . . . . . . . . . . . . . 13 73 4.3.3. Key store . . . . . . . . . . . . . . . . . . . . . . 13 74 4.3.4. Key update . . . . . . . . . . . . . . . . . . . . . 13 75 4.3.5. Key backup . . . . . . . . . . . . . . . . . . . . . 14 76 4.3.6. Key destroy . . . . . . . . . . . . . . . . . . . . . 14 77 4.4. Cert management . . . . . . . . . . . . . . . . . . . . . 14 78 4.4.1. Cert management . . . . . . . . . . . . . . . . . . . 15 79 4.4.2. CRL management . . . . . . . . . . . . . . . . . . . 16 80 5. Infrastructure Layer YANG Module . . . . . . . . . . . . . . 17 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 26 86 9.2. Informative References . . . . . . . . . . . . . . . . . 26 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 89 1. Introduction 91 Network devices such as switches, routers, and firewalls are the 92 fundamental elements that a network is composed of. The 93 vulnerabilities of a network device are always exploited by attackers 94 to start up eavesdropping, spoofing, and man-in-middle attacks etc. 95 Hence it is significant to assess the security postures for 96 identifying the possible threats and vulnerabilities of a network 97 device in anytime. The SACM working group is aim to provide such a 98 mechanism to acquire the posture information, which including the 99 security related configuration and status attributes, on the target 100 devices and evaluate their security postures by comparing with the 101 pre-defined benchmarking criteria. Furthermore, the evaluation 102 results are able to be the guidance to enforce the corresponding 103 security hardening measurement on the devices under assessment. But 104 this hardening process is out of scope of this draft. 106 This draft and each of the companion document define a subset of 107 posture information that have to be collected for the assessment 108 purpose mentioned above. This entire set of posture information is 109 so called security baseline of a network device that is proposed in 110 the companion draft [I-D.draft-xia-sacm-dp-security-profile]. The 111 proposed security baseline is presented in the fashion of yang data 112 model. And the security baseline yang data model can be requested or 113 subscribed by a collector agent such as a yang push client [draft- 114 birkholz-sacm-yang-content]. The output of such a collector agent is 115 then encapsulated into the SACM content and statement elements 116 [draft-ietf-sacm-information-mdoel] and published to other SACM 117 components (e.g. repository and evaluator) [draft-mandm-sacm- 118 architecture-01]. Please note that document is only focus on the 119 yang data model of security baseline, the messaging mechanisms is out 120 of scope of this document. They are specified in other documents. 122 1.1. Infrastructure layer security baseline 124 In general, the entire security baseline of a network device is 125 divided into three layers, namely the application layer, the network 126 layer, and the infrastructure layer. This document focus on the data 127 model on infrastructure layer. The infrastructure layer security 128 baseline herein refers to the configuration and status attributes of 129 security functions that secure the device itself, and the fundamental 130 security capabilities provided by the device to the upper layer 131 applications. More specifically, the essential configurable and key 132 status attributes of the following function/capability modules are 133 sorted out to generate the infrastructure layer security baseline 134 data model. 136 o Integrity measurement: the integrity measurement herein refers to 137 the functions such as trust computing to protect the device 138 against the replacement and/or tampering attacks. For example, 139 the trust boot and/or secure boot provide the integrity validation 140 service for the kernel and early stage executable code (bios and 141 bootloader) in bootstrapping phases, and the digital signature 142 protect the upper layer software applications against the 143 tampering attacks in software updating phases. 145 o Cryptography algorithms: the cryptographic algorithms are the most 146 important capabilities that the device provides to the upper layer 147 security applications. For example, the symmetric (e.g. DES, 148 AES) and asymmetric (eg. RSA, ECC) cryptographic algorithms can 149 be used for sensitive data encryption, and peers authentication. 150 And the key derivation function (KDF) can be used for secret key 151 generation and passcode storage. 153 o Key management: the cryptographic key (pair) and its associated 154 algorithm provide various security features for network devices. 155 How we manage the key (pair) provisioned in a network device is a 156 critical issue. The key management covers the attributes to show 157 how the key (pair) is managed in the key's lifecycle (e.g. from 158 generation to destroy). 160 o Certificate management: the certificates are normally provided by 161 the device for authentication purpose. The certificate management 162 refers to how the certificates and the certificates revocation 163 list (CRL) is requested, updated, and validated in the device. 165 The practical security baseline of a network device depends on the 166 device type, the supported features, the requirements of operators 167 and enterprises, and the role it plays exactly in the network. Owing 168 to such a number of variance, it is impossible to design a 169 comprehensive and unified data model for all devices. Thus the 170 proposed data model in this document is only used to benchmark the 171 most widely deployed security related functions and capabilities. 172 And we would like it to be an extensible model so that more 173 attributes are able to be added as per the practical use case 174 scenario. 176 2. Terminology 178 2.1. Key Words 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 2.2. Definition of Terms 186 This document uses the terms defined in[I-D.ietf-sacm-terminology]. 188 3. Tree Diagrams 190 A simplified graphical representation of the data model is used in 191 this document. The meaning of the symbols in these diagrams is as 192 follows: 194 o Brackets "[" and "]" enclose list keys. 196 o Abbreviations before data node names: "rw" means configuration 197 (read-write) and "ro" state data (read-only). 199 o Symbols after data node names: "?" means an optional node and "*" 200 denotes a "list" and "leaf-list". 202 o Parentheses enclose choice and case nodes, and case nodes are also 203 marked with a colon (":"). 205 o Ellipsis ("...") stands for contents of subtrees that are not 206 shown. 208 4. Data Model Structure 210 As mentioned above, the top-level structure of the data model is 211 shown in the following figure. There are four subtrees in the tree 212 diagram. Each of the following sub-sections specifies the detail of 213 an individual subtree. 215 module: infrastructure-layer-baseline 216 +--rw infrastructure-layer-baseline 217 +--rw integrity-measurement 218 | . . . . . . 219 +--rw cryptography-algorithms 220 | . . . . . . 221 +--rw key-management 222 | . . . . . . 223 +--rw certificate-management 224 . . . . . . 226 4.1. Integrity measurement 228 The purpose of integrity measurement is to prevent the upper layer 229 software applications, kernel, and early stage executable code (e.g. 230 BIOS and bootloader) from replacement and/or tampering in 231 bootstrapping and updating phases. Trusted boot and secure boot are 232 the two widely used techniques for protecting the device 233 bootstrapping. The read-only root of trust (RoT) should be always 234 stored in a SoC or TPM chip. For software updating, digital 235 signature has been demonstrated as a powerful tool to provide the 236 integrity protection service. In using digital signature, the 237 employed hash function and signature algorithm must be strong enough 238 so that attackers cannot force crack them in a short period of time. 239 Moreover, the public key used for verifying the signature should be 240 stored properly. For example, it can be wrapped in a certificate of 241 the software vendor or stored in the read-only SoC or TPM. 243 module: integrity-measurement 244 +--rw integrity-measurement 245 +--rw bootstrapping 246 | +--rw trust-boot 247 | | +--ro tmp-version string 248 | | +--rw tpm-enable boolean 249 | | +---u hash-function 250 | | +--rw pcr-record* [pcr-number] 251 | | +--ro pcr-number unit8 252 | | +--ro measurement-item enumeration 253 | | +--ro pcr-value string 254 | | +--ro pcr-benchmark-value string 255 | | +--ro verify-result boolean 256 | +--rw secure-boot 257 | +--ro soc-model string 258 | +--ro measurement-item* enumeration 259 | +---u hash-function 260 | +---u signature-algorithm 261 | +--ro verification-public-key 262 | +--ro key-name string 263 | +--ro key-length unit16 264 | +--ro key-store-medium enumeration 265 +--rw software-update 266 +---u hash-function 267 +---u signature-algorithm 268 +--ro verification-public-key 269 +--ro key-name string 270 +--ro key-length unit16 271 +--ro key-store-medium enumeration 273 4.2. Cryptography security 275 Almost all the security features of communication network are built 276 on the basis of modern cryptography. For example, the cryptographic 277 algorithms are usually used to perform transmission data encryption 278 and peers authentication. However, as the computing capability of 279 the present computing system is getting faster and faster, more and 280 more cryptographic algorithms can be brute force cracked in a short 281 period of time. Therefore the algorithm has to be selected 282 appropriately for different use case scenarios. And the 283 configuration parameters must be set within an appropriate range so 284 that the used algorithm is strong enough. 286 As a fundamental capabilities provided by the device, the practical 287 configurations of each supported cryptographic algorithm varies as 288 per the upper layer application that employs the algorithm. This 289 section organizes the algorithms and their configuration parameters 290 into groupings so that the upper layer applications can reference/ 291 reuse them appropriately. 293 In general, this section covers the following cryptographic algorithm 294 groupings: 296 o Symmetric algorithms and their configurable parameters. 298 o Asymmetric algorithms and their configurable parameters. 300 o Hash functions. 302 o Message authentication code (MAC) methods and their configurable 303 parameters. 305 o Key derivation functions (KDF) and their configurable parameters. 307 All the groupings enable the collection of the specific algorithms 308 and their parameters on a case-by-case basis. 310 4.2.1. Symmetrical cryptography 312 The symmetric algorithms are typically used for providing data 313 confidential service. The encryption and decryption process of 314 symmetrical algorithms make use of two identical keys. And, most of 315 the symmetrical algorithms are typically belong to either block 316 ciphers or stream ciphers. 318 Block cipher: block cipher divides the plaintext in to a number of 319 blocks with a constant bit length. And the last plaintext block 320 should be filled to fit the bit length requirement. Then each of the 321 plaintext blocks is encrypted individually. However, if a plaintext 322 piece repeats several times in a long data stream, it is easier for 323 an attacker to guess the original plaintext from the repeated 324 ciphertext. Hence, some other operation modes of block cipher, 325 including cipher block chaining (CBC) mode, cipher feedback (CFB) 326 mode, counter mode (CRT), and Galois counter mode (GCM), are proposed 327 to introduce a random bit stream, which is named initialization 328 vector (IV), to augment the randomness of the original plaintext. 329 The used random number generator must meet the randomness requirement 330 so that the IV value is unpredicted. In addition, the bit length of 331 IV should be the same as the bit length of a plaintext block for most 332 block cipher working mode. But for CRT and GCM, the length of IV is 333 optional. 335 Stream cipher: unlike block cipher, which encrypt a single plaintext 336 block at one time, stream-cipher encrypt every bit of a plaintext 337 separately. The stream cipher algorithms also use IV to increase the 338 randomness of the original plaintext. 340 grouping: symmetric-cryptosystem 341 +--rw (algorithm-type) 342 +--:(stream-cipher) 343 | +--rw algorithm identityref 344 | +--rw iv-length unit16 345 | +--rw iv-randomness decimal64 346 +--:(block-cipher) 347 +--rw algorithm identityref 348 +--rw operation-mode identityref 349 +--rw padding-method identityref 350 +--rw iv-length unit16 351 +--rw iv-randomness decimal64 353 4.2.2. Asymmetrical cryptography 355 The asymmetric cryptography is also called public key cryptography. 356 In contrast to the symmetric one, asymmetric cryptography always 357 employs a key pair that contains two different keys to deal with the 358 encryption and decryption work. The private key in the key pairs is 359 held and used only by the owner. The other key in the key pairs is 360 theoretically public to everyone. The asymmetric cryptography 361 algorithms are not only able to provide data encryption, but also 362 provide authentication and/or integrity protection services (e.g. 363 digital signature). 365 Asymmetric encryption: RSA is the most commonly used asymmetrical 366 encryption algorithm. In the use of RSA, the smaller the public 367 exponent is, the higher efficiency the algorithm has. In the other 368 side, it will be much easier to crack the algorithm and recover the 369 original plaintext if the public exponent is too small. Hence it has 370 to trade off the value of public exponent. In addition, the RSA is 371 recommend to use optimal asymmetrical encryption padding (OAEP) to 372 fill up the original plaintext. 374 grouping: encryption-algorithm 375 +--rw encryption-algorithm 376 +--rw rsa-attributes 377 +--rw algorithm identityref 378 +--rw padding-method identityref 379 +--rw public-key 380 +--rw public-exponent unit32 381 +--rw modulo-value unit32 383 Digital signature: digital signature is a powerful tool to provide 384 integrity protection. DSA, RSA, and ECDSA are three of the most 385 popular signature algorithms. By using RSA in digital signature, it 386 is better to use PSS for padding. If the data is required to be 387 encrypted and signed at the same time, it is suggest to sign the data 388 before encrypting. 390 grouping: signature-algorithms 391 +--rw (asymmetric-algorithms) 392 +--:(rsa) 393 | +--rw algorithm identityref 394 | +--rw padding-method identityref 395 | +--rw public-key 396 | +--rw public-exponent unit32 397 | +--rw modulo-value unit32 398 +--:(dsa) 399 | +--rw temporary-key 400 | | +--rw key-length unit16 401 | | +--rw randomness decimal64 402 | +--rw prime-number 403 | +--rw prime-modulo unit32 404 | +--rw prime-order unit32 405 +--:(ecdsa) 406 +--rw temporary-key 407 | +--rw key-length unit16 408 | +--rw randomness decimal64 409 +---u hash-function 410 +--rw prime-modulo unit32 411 +--rw prime-order unit32 412 +--rw ec-parameters 413 +--rw coefficient-a unit16 414 +--rw coefficient-b unit16 416 Key exchange: key exchange is meant to establish key pairs between 417 communication peers. The peers send key material rather than key 418 itself to each other. 420 grouping: key-exchange 421 +--rw (key-exchange) 422 +--:(dh) 423 | +--rw dh-handshake 424 | +--rw prime-number-length unit32 425 | +--rw public-integer-length unit32 426 +--:(ecdh) 427 +--rw ecdh-handshake 428 +--rw prime-modulo unit32 429 +--rw ec-parameters 430 | +--rw coefficient-a unit16 431 | +--rw coefficient-b unit16 432 +--rw primitive-elements 433 +--rw coordinate-x unit16 434 +--rw coordinate-y unit16 436 4.2.3. Hash function 438 Hash functions are normally used to perform integrity measurement. 439 The output of a Hash function is a digest with a constant bit length 440 for a segment of messages or code. The digest is unique and unable 441 to be reconstructed if the original message/code is tampered. The 442 Hash function is widely used in digital signature, message 443 authentication code, password hash storage, and etc. 445 grouping: hash-function 446 +--rw hash-function 447 +--rw algorithm identityref 448 +--rw padding-method identityref 449 +--ro digest-length unit16 451 4.2.4. Message authentication code 453 Similar to digital signature, message authentication code (MAC) is 454 another method to provide integrity protection service. MAC applies 455 hash function or block cipher algorithms on the message plaintext 456 coupled with a pre-shared session key. It must be noted that, it is 457 unsafe if simply extend the message with the session key. 459 grouping: message-authentication-code 460 +--rw (message-authentication-code) 461 +--: (hmac) 462 | +--rw message-structure enumeration 463 | | {prefix|postfix|hmac structure} 464 | +---u hash-function 465 | +--rw session-key 466 | +--rw key-length unit16 467 | +--rw randomness decimal64 468 +--: (cmac) 469 +--rw block-cipher-algorithm identityref 470 +--rw block-length unit16 471 +--rw iv-length unit16 472 +--rw randomness decimal64 474 4.2.5. Key derivation function 476 Key derivation function derives one or more keys from a master key or 477 entered password. A salt value is generated by a random number 478 generator to introduce the randomness of the derived keys. 480 grouping: key-derivation-function 481 +--rw (algorithm) 482 +--:(pbkdf2) 483 | +---u hash-function 484 | +--rw iteration unit16 485 | +--rw derived-key-length unit16 486 | +--rw code-length unit16 487 | +--rw salt-attributes 488 | +--rw salt-length unit16 489 | +--rw randomness decimal64 490 +--:(scrypt) 491 +--rw code-length unit16 492 +--rw cpu-memory-usage unit16 493 +--rw block-size unit8 494 +--rw parallelization unit8 495 +--rw derived-key-length unit16 496 +--rw salt-attributes 497 +--rw salt-length unit16 498 +--rw randomness decimal64 500 4.3. Key management 502 Cryptographic key plays the most important role in a cryptographic 503 system. . If the key is disclosed or tampered, the corresponding 504 service is not reliable any more. Hence the network device must 505 provide the confidentiality and integrity protection for a key in its 506 entire lifecycle. This section contains a list of key (pair) and 507 their configuration/status parameters corresponding to different 508 lifecycle phases. Each of the key (pair) is used in a specific use 509 case. 511 module: key-management 512 +--rw key-management* [key-name] 513 +--rw key-name string 514 +--rw key-length* unit16 515 +--rw lifetime unit32 516 +--rw key-type enumeration 517 +--rw num-of-keys unit8 518 +--rw key-generation 519 | . . . . . . 520 +--rw key-distribution 521 | . . . . . . 522 +--rw key-store 523 | . . . . . . 524 +--rw key-backup 525 | . . . . . . 526 +--rw key-update 527 | . . . . . . 528 +--rw key-destroy 529 . . . . . . 531 4.3.1. Key generation 533 There are three types of commonly used key generation methods. The 534 first method is on the basis of random number generator. In this 535 method, the referenced random number generator has to ensure the 536 generated key is unpredicted. The second key generation method is 537 based on the manual entered password. However, the entered password 538 is not meet the randomness requirement. In this case, a key 539 derivation function (e.g. PBKDF2) is applied to derive the key. The 540 last key generation method is key exchange such as Diffie-Hellman 541 (DH) protocol. This kind of method requires the peers to 542 authenticate each other before exchange the key material. 544 submodule: key-generation 545 +--rw key-generation 546 +--: (random-number-generator) 547 | +--rw key-randomness decimal64 548 +--: (key-derivation-function) 549 | +---u key-derivation-function 550 +--: (key-exchange) 551 +--rw cert-name string 552 +---u key-exchange 554 4.3.2. Key distribution 556 Key distribution aims to send the generated keys to authorized 557 entities in a secure fashion. The confidentiality and integrity 558 issues of the key in distribution are usually addressed by using 559 either a secure transport protocol or digital envelop. 560 [I-D.ietf-netconf-tls-client-server], IPsec [I-D.draft-tran-ipsecme- 561 yang], or SSH [I-D.ietf-netconf-ssh-client-server], or digital 562 envelop. 564 submodule: key-distribution 565 +--rw key-distribution? 566 +--rw symmetrical-key 567 +--: (secure-transport-protocol) 568 | +--rw tls-config 569 | | [I-D.ietf-netconf-tls-client-server] 570 | +--rw ipsec-config 571 | | [I-D.draft-tran-ipsecme-yang] 572 | +--rw ssh-config 573 | [I-D.ietf-netconf-ssh-client-server] 574 +--: (digital-envolop) 575 +---u symmetric-algorithm 576 +--rw encryption-key-name string 577 +--rw encryption-key-length unit16 579 4.3.3. Key store 581 A typical key management system has three layers. The master keys 582 that consumed by upper layer applications are in the top layer. The 583 key in the middle layer, which is called key encryption key (KEK), is 584 used to encrypt the master keys. And the KEK itself is encrypted by 585 the root key which stays in the bottom layer of the three layer key 586 management system. 588 submodule: key-store 589 +--rw key-store 590 +--ro store-medium {TPM|HSM|HDD} enumeration 591 +--rw key-component* [component-name] 592 +--rw component-name string 593 +--ro store-medium enumeration 595 4.3.4. Key update 597 Network device must update the key in a reasonable period of time. 598 Otherwise the long term used key will attract attackers to crack it. 599 The practical update period of a certain key depends on the 600 application the key serves and the strength (i.e. bit length) of the 601 key itself. 603 submodule: key-update 604 +--rw key-update 605 +--rw next-update-time yang-type:date-and-time 606 +--rw hold-expired-key boolean 607 +--rw update-mode 608 +--: (manual) 609 | +--rw manual-enable boolean 610 +--: (auto) 611 +--rw auto-enble boolean 612 +--rw update-period unit8 614 4.3.5. Key backup 616 The loss of keys will lead to data loss. Therefore, according to the 617 different use case scenarios, a key (pair) may need to backup. It is 618 better to divide the key into several parts and store them into 619 different storage devices. 621 submodule: key-backup 622 +--rw key-backup? 623 +--rw backup-enable boolean 624 +--rw backup-expire-time yang-type:date-and-time 625 +--rw backup-component* [component-name] 626 +--rw component-name string 627 +--ro backup-medium enumeration 629 4.3.6. Key destroy 631 The key and its associated key material must be destroyed when it is 632 expired. Otherwise the expired key will be used by attackers to 633 decrypt the data encrypted by this key. Also, the expired key can be 634 used to analysis the cryptosystem. 636 submodule: key-destory 637 +--rw key-destory 638 +--rw method {one|zerod|random number} enumeration 639 +--rw number-of-times unit8 641 4.4. Cert management 643 The TLS/DTLS and IPsec have been demonstrated as powerful security 644 tools to provide data confidentiality and integrity services between 645 network elements. In order to protect the TLS/DTLS or the IPsec 646 connection against man-in-middle attack, peers have to authenticate 647 from each other before connection establishing. The pre-shared key 648 and the certificate are two of the most widely used methods to 649 authenticate peers' identities. However, it requires to re-configure 650 the pre-shared keys on all other endpoints/network elements if an 651 additional network device is added in network. This complicated re- 652 configuration process is easy to make errors. In the other hand, 653 certificate is an idea way to extend authentications to a much larger 654 scale of network. Peers request certificates that contain their 655 entity information and public keys from certification authority (CA) 656 in advance. The connection will be established only if the 657 certificates are verified. 659 For a specific network device, such as switch and router, the 660 certification service normally includes certificates request and 661 updating, certificates validity check. 663 module: cert-management 664 +--rw cert-management 665 +--rw cert-management 666 | . . . . . . 667 +--rw crl-management 668 . . . . . . 670 4.4.1. Cert management 672 A cert request file that contains the device public key and entity 673 information is sent to the CA to apply a certificate. A CMP session 674 is configured to request and update the certificates. A build-in 675 default certificate in the device is used for identity authentication 676 for CMP session. And the certificate must be updated in a reasonable 677 period of time via CMP session. 679 module: cert-management 680 +--rw cert-management* [cert-name] 681 +--rw cert-name string 682 +--ro version string 683 +--ro serial-number string 684 +--ro signature-algorithm identityref 685 +--ro issuer-name string 686 +--rw cert-request 687 | +--rw cmp-session-name string 688 +--ro validity 689 | +--ro start-time yang-type:date-and-time 690 | +--ro end-time yang-type:data-and-time 691 +--ro subject-public-key 692 | +--ro public-key-algorithm identityref 693 | +--ro public-key-length unit16 694 | +--ro exponent unit32 695 +--rw cert-auto-update 696 +--rw cert-name string 697 +--rw pki-domain-name string 698 +--rw cmp-session-name string 699 +--rw auto-update-enable boolean 700 +--rw trigger-condition 701 +--rw validity-percentage-number unit8 703 grouping: cmp-session-config 704 +--rw cmp-session-config* [session-name] 705 +--rw domain-name string 706 +--rw session-name string 707 +--rw entity-name string 708 +--rw key-name string 709 +--rw ca-server-name string 710 +--rw default-cert-name string 711 +--rw cmp-server-url string 713 4.4.2. CRL management 715 The certificate revocation list (CRL) contains the invalid/expired 716 certificates. It is equivalent to a blacklist of certificates issued 717 by CA. The validity of a received cert is able to be checked by 718 comparing with the CRL. The CRL need to update from CA by either an 719 automatic or manual way. 721 submodule: crl-management 722 +--rw crl-management 723 +--rw cert-validity-check-enable boolean 724 +--rw crl-update 725 +--rw previous-update-time yang-type:date-and-time 726 +--rw auto-update 727 | +--rw auto-update-enable boolean 728 | +--rw update-period unit32 729 | +--rw next-update-time yang-type:date-and-time 730 | +--rw update-method {http|ldap} enumeration 731 +--rw manual-update 732 +--rw manual-update-enable boolean 733 +--rw update-method {http|ldap} enumeration 735 5. Infrastructure Layer YANG Module 737 This section shows a fraction of the infrastructure layer security 738 baseline YANG modules. 740 module ietf-integrity-measurement{ 741 yang-version 1.1; 743 namespace "urn:ietf:params:xml:ns:yang:ietf-integrity-measurement"; 744 prefix "im"; 746 import ietf-yang-types{ 747 prefix yang; 748 reference 749 "RFC6991: Common Yang Data Types"; 750 } 752 organization 753 "Huawei Technologies"; 755 contact 756 "Yue Dong: dongyue6@huawei.com" 757 "Liang Xia: Frank.xialiang@huawei.com" 759 description 760 "This module defines the configuration and status parameters of the 761 functions that provide the integrity services in the bootstrapping 762 and software updating phases."; 764 identity hash-algorithms { 765 description 766 "base identities of hash algorithms options"; 767 } 768 identity md5 { 769 base hash-algorithms; 770 description 771 "The MD5 algorithm"; 772 } 774 identity sha1 { 775 base hash-algorithms; 776 description 777 "The SHA-1 algorithm"; 778 reference 779 "RFC3174: US Secure Hash Algorithm 1 (SHA1)."; 780 } 782 identity sha224 { 783 base hash-algorithms; 784 description 785 "The SHA-224 algorithm."; 786 reference 787 "RFC6234: US Secure Hash Algorithms (SHA and SHA based HMAC and 788 HKDF)."; 789 } 791 identity sha256 { 792 base hash-algorithms; 793 description 794 "The SHA-256 algorithm."; 795 reference 796 "RFC6234: US Secure Hash Algorithms (SHA and SHA based HMAC and 797 HKDF)."; 798 } 800 identity sha384 { 801 base hash-algorithms; 802 description 803 "The SHA-384 algorithm."; 804 reference 805 "RFC6234: US Secure Hash Algorithms (SHA and SHA based HMAC and 806 HKDF)."; 807 } 809 identity sha512 { 810 base hash-algorithm; 811 description 812 "The SHA-512 algorithm."; 813 reference 814 "RFC6234: US Secure Hash Algorithms (SHA and SHA based HMAC and 815 HKDF)."; 817 } 819 identity rsa-algorithms { 820 description 821 "rsa algorithms with different key length"; 822 } 824 identity rsa1024 { 825 base rsa-algorithms; 826 description 827 "The RSA algorithm using a 1024 bit key"; 828 reference 829 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 830 Cryptography Specifications 2.1" 831 } 833 identity rsa2048 { 834 base rsa-algorithms; 835 description 836 "The RSA algorithm using a 2048 bit key"; 837 reference 838 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 839 Cryptography Specifications 2.1" 840 } 842 identity rsa3072 { 843 base rsa-algorithms; 844 description 845 "The RSA algorithm using a 3072 bit key"; 846 reference 847 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 848 Cryptography Specifications 2.1" 849 } 851 identity rsa4096 { 852 base rsa-algorithms; 853 description 854 "The RSA algorithm using a 4096 bit key"; 855 reference 856 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 857 Cryptography Specifications 2.1" 858 } 860 identity rsa7680 { 861 base rsa-algorithms; 862 description 863 "The RSA algorithm using a 7680 bit key"; 864 reference 865 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 866 Cryptography Specifications 2.1" 867 } 869 identity rsa15360 { 870 base rsa-algorithms; 871 description 872 "The RSA algorithm using a 15360 bit key"; 873 reference 874 "RFC3447: Public-Key Cryptography Standards (PKCS) #1: RSA 875 Cryptography Specifications 2.1" 876 } 878 identity rsa-padding { 879 description 880 "The identities of padding methods for rsa."; 881 } 883 identity oaep { 884 base rsa-padding; 885 description 886 "The OAEP padding method for RSA."; 887 } 889 identity pss { 890 base rsa-padding; 891 description 892 "The PSS padding method for RSA."; 893 } 895 container integrity-measurement { 896 container bootstrapping { 897 container trust-boot { 898 leaf tpm-version { 899 type string; 900 description 901 "version of the tpm chip"; 902 } 904 leaf tpm-enable { 905 type boolean; 906 description 907 "switch of the trust boot function"; 908 } 910 uses hash-function 912 list pcr-record { 913 key "pcr-number"; 915 leaf pcr-number { 916 type unit8; 917 description 918 "Number of pcr register"; 919 } 921 leaf measurement-item{ 922 type enumeration { 923 enum bios; 924 enum bootloader; 925 enum kernel; 926 enum patch; 927 } 928 description 929 "This property shows which item is measured and recored by 930 the pcr"; 931 } 933 leaf pcr-value { 934 type string; 935 description 936 "The practical measurement value"; 937 } 939 leaf pcr-benchmark-value { 940 type string; 941 description 942 "The pre-defined benchmark criterion"; 943 } 945 leaf verify-result { 946 type boolean; 947 description 948 "The benchmark result for each pcr recorded value"; 949 } 950 } 951 } 953 container secure-boot { 954 leaf soc-model { 955 type string; 956 description 957 "Model of the used SoC"; 958 } 960 leaf-list measurement-items { 961 type enumeration { 962 enum bios; 963 enum bootloader; 964 enum kernel; 965 enum patch; 966 } 967 description 968 "List of the items to be measured in the secure boot 969 process"; 970 } 972 uses hash-function 974 uses signature-algorithm 976 container verification-pub-key { 977 leaf key-name { 978 type string; 979 description 980 "Name of the public key for verfication"; 981 } 983 leaf key-length { 984 type unit16; 985 description 986 "Length of the public key" 987 } 989 leaf store-medium { 990 type enumeration { 991 enum tmp; 992 enum soc; 993 enum hdd; 994 enum hsm; 995 } 996 description 997 "This property describes where the public key stores" 998 } 999 } 1000 } 1001 } 1003 container software-update { 1004 uses hash-function; 1006 uses signature-algorithm; 1008 container verification-pub-key { 1009 leaf key-name { 1010 type string; 1011 description 1012 "Name of the public key for verification"; 1013 } 1015 leaf key-length { 1016 type unit16; 1017 description 1018 "Length of the public key"; 1019 } 1021 leaf store-medium { 1022 type enumeration { 1023 enum tpm; 1024 enum soc; 1025 enum hdd; 1026 enum hsm; 1027 } 1028 description 1029 "This property decribes where the pub key stores" 1030 } 1031 } 1032 } 1033 } 1035 grouping hash-function { 1036 description 1037 "A group of Hash functions and their parameters"; 1039 leaf algorithm { 1040 type identityref { 1041 base "hash-algorithm"; 1042 } 1043 description 1044 "Identities of the used Hash algorithm"; 1045 } 1047 leaf padding-method { 1048 type identityref; 1049 description 1050 "" 1051 } 1053 leaf digest-length { 1054 type unit16; 1055 description 1056 "The length of the Hash output"; 1058 } 1059 } 1061 grouping signature-algorithms { 1062 "A group of algorithms and their configurable parameters for digital 1063 signature"; 1065 choice algorithm-type { 1066 case rsa { 1067 leaf algorithm { 1068 type identityref { 1069 base "rsa-algorithm"; 1070 } 1071 description 1072 "identities of the rsa algorithms for digital signature"; 1073 } 1075 leaf padding-method { 1076 type identityref; 1077 description 1078 "identities of padding method for the used algorithm" 1079 } 1081 container pub-key { 1082 leaf public-exponent { 1083 type unit32; 1084 description 1085 "value of public exponent"; 1086 } 1088 leaf modulo-value { 1089 type unit32; 1090 description 1091 "value of modulo"; 1092 } 1093 } 1094 } 1096 case dsa { 1097 container tempory-key { 1098 leaf key-length { 1099 type unit16; 1100 description 1101 "The length of the tempory key."; 1102 } 1104 leaf randomness { 1105 type decimal64; 1106 description 1107 "This value represents the randomness of this key."; 1108 } 1109 } 1111 container prime-number { 1112 leaf prime-modulo { 1113 type unit32; 1114 description 1115 "value of modulo"; 1116 } 1118 leaf prime-order { 1119 type unit32; 1120 description 1121 "value of prime number"; 1122 } 1123 } 1124 } 1126 case ecdsa { 1127 containter tempory-key { 1128 leaf key-length { 1129 type unit16; 1130 description 1131 "The length of the tempory key that is generated by a 1132 random number generator."; 1133 } 1135 leaf randomness { 1136 type decimal64 1137 description 1138 "This value represents the randomness of the key. It is 1139 generated by a tool like sts 2.1."; 1140 } 1141 } 1143 leaf prime-modulo { 1144 type unit32; 1145 description 1146 "value of modulo"; 1147 } 1149 leaf prime-order { 1150 type unit32; 1151 description 1152 "value of order"; 1153 } 1154 uses hash-function 1156 container ec-parameter { 1157 leaf coefficient-a { 1158 type unit8; 1159 description 1160 "constant coefficient of the selected elliptic curve."; 1161 } 1163 leaf coefficient-b { 1164 type unit8; 1165 description 1166 "constant coefficient of the selected elliptic curve."; 1167 } 1168 } 1169 } 1170 } 1171 } 1172 } 1174 6. IANA Considerations 1176 TBD 1178 7. Security Considerations 1180 TBD. 1182 8. Acknowledgements 1184 TBD 1186 9. References 1188 9.1. Normative References 1190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1191 Requirement Levels", BCP 14, RFC 2119, 1192 DOI 10.17487/RFC2119, March 1997, 1193 . 1195 9.2. Informative References 1197 [I-D.ietf-netconf-ssh-client-server] 1198 Watsen, K. and G. Wu, "YANG Groupings for SSH Clients and 1199 SSH Servers", draft-ietf-netconf-ssh-client-server-05 1200 (work in progress), October 2017. 1202 [I-D.ietf-netconf-tls-client-server] 1203 Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and 1204 TLS Servers", draft-ietf-netconf-tls-client-server-05 1205 (work in progress), October 2017. 1207 [I-D.ietf-sacm-information-model] 1208 Waltermire, D., Watson, K., Kahn, C., Lorenzin, L., Cokus, 1209 M., Haynes, D., and H. Birkholz, "SACM Information Model", 1210 draft-ietf-sacm-information-model-10 (work in progress), 1211 April 2017. 1213 [I-D.ietf-sacm-terminology] 1214 Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and 1215 A. Montville, "Security Automation and Continuous 1216 Monitoring (SACM) Terminology", draft-ietf-sacm- 1217 terminology-14 (work in progress), December 2017. 1219 [I-D.mandm-sacm-architecture] 1220 Montville, A. and B. Munyan, "Security Automation and 1221 Continuous Monitoring (SACM) Architecture", draft-mandm- 1222 sacm-architecture-01 (work in progress), March 2018. 1224 [I-D.tran-ipsecme-yang] 1225 Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data 1226 Model for Internet Protocol Security (IPsec)", draft-tran- 1227 ipsecme-yang-00 (work in progress), October 2015. 1229 [I-D.xia-sacm-nid-dp-security-baseline] 1230 Xia, L. and G. Zheng, "The Data Model of Network 1231 Infrastructure Device Data Plane Security Baseline", 1232 draft-xia-sacm-nid-dp-security-baseline-01 (work in 1233 progress), January 2018. 1235 Authors' Addresses 1237 Yue Dong 1238 Huawei 1240 Email: dongyue6@huawei.com 1242 Liang Xia 1243 Huawei 1245 Email: frank.xialiang@huawei.com