idnits 2.17.1 draft-ietf-opsawg-mud-tls-02.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 : ---------------------------------------------------------------------------- ** There are 41 instances of too long lines in the document, the longest one being 30 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 428 has weird spacing: '... cipher ian...' -- The document date (October 21, 2020) is 1254 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) -- Looks like a reference, but probably isn't: '10' on line 1004 -- Looks like a reference, but probably isn't: '11' on line 1004 -- Looks like a reference, but probably isn't: '13' on line 1004 -- Looks like a reference, but probably isn't: '16' on line 1004 -- Looks like a reference, but probably isn't: '24' on line 1004 -- Looks like a reference, but probably isn't: '29' on line 1005 == Missing Reference: 'RFCXXXX' is mentioned on line 1174, but not defined == Missing Reference: 'RFC5246' is mentioned on line 1191, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'RFC6346' is mentioned on line 1208, but not defined == Unused Reference: 'RFC6991' is defined on line 1301, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-18 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 8701 -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-07 == Outdated reference: A later version (-09) exists of draft-ietf-uta-tls13-iot-profile-00 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG WG T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track D. Wing 5 Expires: April 24, 2021 Citrix 6 B. Anderson 7 Cisco 8 October 21, 2020 10 Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices 11 draft-ietf-opsawg-mud-tls-02 13 Abstract 15 This memo extends the Manufacturer Usage Description (MUD) 16 specification to incorporate (D)TLS profile parameters. This allows 17 a network security service to identify unexpected (D)TLS usage, which 18 can indicate the presence of unauthorized software or malware on an 19 endpoint. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 24, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Overview of MUD (D)TLS profiles for IoT devices . . . . . . . 5 58 4. (D)TLS 1.3 Handshake . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Full (D)TLS 1.3 Handshake Inspection . . . . . . . . . . 6 60 4.2. Encrypted DNS . . . . . . . . . . . . . . . . . . . . . . 7 61 5. (D)TLS Profile of a IoT device . . . . . . . . . . . . . . . 7 62 5.1. Tree Structure of the (D)TLS profile Extension to the ACL 63 YANG Model . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.2. The (D)TLS profile Extension to the ACL YANG Model . . . 10 65 5.3. IANA (D)TLS profile YANG Module . . . . . . . . . . . . . 15 66 5.4. MUD (D)TLS Profile Extension . . . . . . . . . . . . . . 18 67 6. Processing of the MUD (D)TLS Profile . . . . . . . . . . . . 20 68 7. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 20 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 70 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 72 10.1. (D)TLS Profile YANG Modules . . . . . . . . . . . . . . 23 73 10.2. TLS Version registry . . . . . . . . . . . . . . . . . . 25 74 10.3. DTLS version registry . . . . . . . . . . . . . . . . . 26 75 10.4. (D)TLS Parameters registry . . . . . . . . . . . . . . . 26 76 10.5. MUD Extensions registry . . . . . . . . . . . . . . . . 27 77 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 79 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 80 12.2. Informative References . . . . . . . . . . . . . . . . . 29 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 83 1. Introduction 85 Encryption is necessary to enhance the privacy of end users using IoT 86 devices. TLS [RFC8446] and DTLS [I-D.ietf-tls-dtls13] are the 87 dominant protocols (counting all (D)TLS versions) providing 88 encryption for IoT device traffic. Unfortunately, in conjunction 89 with IoT applications' rise of encryption, malware authors are also 90 using encryption which thwarts network-based analysis such as deep 91 packet inspection (DPI). Other mechanisms are thus needed to help 92 detecting malware running on an IoT device. 94 Malware frequently uses proprietary libraries for its activities, and 95 those libraries are reused much like any other software engineering 96 project. [malware] indicates that there are observable differences in 97 how malware uses encryption compared with how non-malware uses 98 encryption. There are several interesting findings specific to 99 (D)TLS which were found common to malware: 101 o Older and weaker cryptographic parameters (e.g., 102 TLS_RSA_WITH_RC4_128_SHA). 104 o TLS server name indication (SNI) extension [RFC6066] and server 105 certificates are composed of subjects with characteristics of a 106 domain generation algorithm (DGA) (e.g., 'www.33mhwt2j.net'). 108 o Higher use of self-signed certificates compared with typical 109 legitimate software. 111 o Discrepancies in the SNI TLS extension and the DNS names in the 112 SubjectAltName (SAN) X.509 extension in the server certificate 113 message. 115 o Discrepancies in the key exchange algorithm and the client public 116 key length in comparison with legitimate flows. As a reminder, 117 the Client Key Exchange message has been removed from TLS 1.3. 119 o Lower diversity in TLS client advertised extensions compared to 120 legitimate clients. 122 o Using privacy enhancing technologies like Tor, Psiphon, Ultrasurf 123 (see [malware-tls]), and evasion techniques such as ClientHello 124 randomization. 126 o Using DNS-over-HTTPS (DoH) [RFC8484] to avoid detection by malware 127 DNS filtering services [malware-doh]. Specifically, malware may 128 not use the DoH server provided by the local network. 130 If observable (D)TLS profile parameters are used, the following 131 functions are possible which have a positive impact on the local 132 network security: 134 o Permit intended DTLS or TLS use and block malicious DTLS or TLS 135 use. This is superior to the layers 3 and 4 ACLs of Manufacturer 136 Usage Description Specification (MUD) [RFC8520] which are not 137 suitable for broad communication patterns. 139 o Ensure TLS certificates are valid. Several TLS deployments have 140 been vulnerable to active Man-In-The-Middle (MITM) attacks because 141 of the lack of certificate validation or vulnerability in the 142 certificate validation function (see [cryto-vulnerability]). By 143 observing (D)TLS profile parameters, a network element can detect 144 when the TLS SNI mismatches the SubjectAltName and when the 145 server's certificate is invalid. In TLS 1.2, the ClientHello, 146 ServerHello and Certificate messages are all sent in clear-text. 147 This check is not possible with TLS 1.3, which encrypts the 148 Certificate message thereby hiding the server identity from any 149 intermediary. In TLS 1.3, the server certificate validation 150 functions should be executed within an on-path TLS proxy, if such 151 a proxy exists. 153 o Support new communication patterns. An IoT device can learn a new 154 capability, and the new capability can change the way the IoT 155 device communicates with other devices located in the local 156 network and Internet. There would be an inaccurate policy if an 157 IoT device rapidly changes the IP addresses and domain names it 158 communicates with while the MUD ACLs were slower to update (see 159 [clear-as-mud]). In such a case, observable (D)TLS profile 160 parameters can be used to permit intended use and to block 161 malicious behavior from the IoT device. 163 The YANG module specified in Section 5 of this document is an 164 extension of YANG Data Model for Network Access Control Lists (ACLs) 165 [RFC8519] to enhance MUD [RFC8520] to model observable (D)TLS profile 166 parameters. Using these (D)TLS profile parameters, an active MUD- 167 enforcing network security service (e.g., firewall) can identify MUD 168 non-compliant (D)TLS behavior indicating outdated cryptography or 169 malware. This detection can prevent malware downloads, block access 170 to malicious domains, enforce use of strong ciphers, stop data 171 exfiltration, etc. In addition, organizations may have policies 172 around acceptable ciphers and certificates for the websites the IoT 173 devices connect to. Examples include no use of old and less secure 174 versions of TLS, no use of self-signed certificates, deny-list or 175 accept-list of Certificate Authorities, valid certificate expiration 176 time, etc. These policies can be enforced by observing the (D)TLS 177 profile parameters. Network security services can use the IoT 178 device's (D)TLS profile parameters to identify legitimate flows by 179 observing (D)TLS sessions, and can make inferences to permit 180 legitimate flows and to block malicious or insecure flows. The 181 proposed technique is also suitable in deployments where decryption 182 techniques are not ideal due to privacy concerns, non-cooperating 183 end-points, and expense. 185 2. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in BCP 190 14 [RFC2119][RFC8174] when, and only when, they appear in all 191 capitals, as shown here. 193 "(D)TLS" is used for statements that apply to both Transport Layer 194 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 195 Specific terms are used for any statement that applies to either 196 protocol alone. 198 'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS. 200 3. Overview of MUD (D)TLS profiles for IoT devices 202 In Enterprise networks, protection and detection are typically done 203 both on end hosts and in the network. Host security agents have deep 204 visibility on the devices where they are installed, whereas the 205 network has broader visibility. Installing host security agents may 206 not be a viable option on IoT devices, and network-based security is 207 an efficient means to protect such IoT devices. If the IoT device 208 supports a MUD (D)TLS profile, the (D)TLS profile parameters of the 209 IoT device can be used by a middlebox to detect and block malware 210 communication, while at the same time preserving the privacy of 211 legitimate uses of encryption. The middlebox need not proxy (D)TLS 212 but can passively observe the parameters of (D)TLS handshakes from 213 IoT devices and gain visibility into TLS 1.2 parameters and partial 214 visibility into TLS 1.3 parameters. 216 Malicious agents can try to use the (D)TLS profile parameters of 217 legitimate agents to evade detection, but it becomes a challenge to 218 mimic the behavior of various IoT device types and IoT device models 219 from several manufacturers. In other words, malware developers will 220 have to develop malicious agents per IoT device type, manufacturer 221 and model, infect the device with the tailored malware agent and will 222 have keep up with updates to the device's (D)TLS profile parameters 223 over time. Furthermore, the malware's command and control server 224 certificates need to be signed by the same certifying authorities 225 trusted by the IoT devices. Typically, IoT devices have an 226 infrastructure that supports a rapid deployment of updates, and 227 malware agents will have a near-impossible task of similarly 228 deploying updates and continuing to mimic the TLS behavior of the IoT 229 device it has infected. However, if the IoT device has reached end- 230 of-life and the IoT manufcaturer will not issue a firmware or 231 software update to the Thing or will not update the MUD file, the 232 "is-supported" attribute defined in Section 3.6 of [RFC8520] can be 233 used by the MUD manager to identify the IoT manufcaturer no longer 234 supports the device. 236 The end-of-life of a device does not necessarily mean that it is 237 defective; rather, it denotes a need to replace and upgrade the 238 network to next-generation devices for additional functionality. The 239 network security service will have to rely on other techniques 240 discussed in Section 8 to identify malicious connections until the 241 device is replaced. 243 Compromised IoT devices are typically used for launching DDoS attacks 244 (Section 3 of [RFC8576]). For example, DDoS attacks like Slowloris 245 and Transport Layer Security (TLS) re-negotiation can be blocked if 246 the victim's server certificate is not be signed by the same 247 certifying authorities trusted by the IoT device. 249 4. (D)TLS 1.3 Handshake 251 In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since 252 all (D)TLS handshake messages excluding the ClientHello message are 253 encrypted. (D)TLS 1.3 has introduced new extensions in the handshake 254 record layers called Encrypted Extensions. Using these extensions 255 handshake messages will be encrypted and network security services 256 (such as a firewall) are incapable to decipher the handshake, and 257 thus cannot view the server certificate. However, the ClientHello 258 and ServerHello still have some fields visible, such as the list of 259 supported versions, named groups, cipher suites, signature algorithms 260 and extensions in ClientHello, and chosen cipher in the ServerHello. 261 For instance, if the malware uses evasion techniques like ClientHello 262 randomization, the observable list of cipher suites and extensions 263 offered by the malware agent in the ClientHello message will not 264 match the list of cipher suites and extensions offered by the 265 legitimate client in the ClientHello message, and the middlebox can 266 block malicious flows without acting as a (D)TLS 1.3 proxy. 268 4.1. Full (D)TLS 1.3 Handshake Inspection 270 To obtain more visibility into negotiated TLS 1.3 parameters, a 271 middlebox can act as a (D)TLS 1.3 proxy. A middlebox can act as a 272 (D)TLS proxy for the IoT devices owned and managed by the IT team in 273 the Enterprise network and the (D)TLS proxy must meet the security 274 and privacy requirements of the organization. In other words, the 275 scope of middlebox acting as a (D)TLS proxy is restricted to 276 Enterprise network owning and managing the IoT devices. The 277 middlebox would have to follow the behaviour detailed in Section 9.3 278 of [RFC8446] to act as a compliant (D)TLS 1.3 proxy. 280 To further increase privacy, Encrypted Client Hello (ECH) extension 281 [I-D.ietf-tls-esni] prevents passive observation of the TLS Server 282 Name Indication extension and other potentially sensitive fields, 283 such as the ALPN [RFC7301]. To effectively provide that privacy 284 protection, ECH extension needs to be used in conjunction with DNS 285 encryption (e.g., DoH). A middlebox (e.g., firewall) passively 286 inspecting ECH extension cannot observe the encrypted SNI nor observe 287 the encrypted DNS traffic. 289 4.2. Encrypted DNS 291 A common usage pattern for certain type of IoT devices (e.g., light 292 bulb) is for it to "call home" to a service that resides on the 293 public Internet, where that service is referenced through a domain 294 name (A or AAAA record). As discussed in Manufacturer Usage 295 Description Specification [RFC8520], because these devices tend to 296 require access to very few sites, all other access should be 297 considered suspect. If an IoT device is pre-configured to use public 298 DoH/DoT server, the MUD policy enforcement point is moved to that 299 public server, which cannot enforce the MUD policy based on domain 300 names (Section 8 of [RFC8520]). If the DNS query is not accessible 301 for inspection, it becomes quite difficult for the infrastructure to 302 suspect anything. Thus the use of a public DoH/DoT server is 303 incompatible with MUD in general. A local DoH/DoT server is 304 necessary to allow MUD policy enforcement on the local network 305 [I-D.reddy-add-enterprise]. 307 5. (D)TLS Profile of a IoT device 309 This document specifies a YANG module for representing (D)TLS 310 profile. The (D)TLS profile YANG module provides a method for 311 network security services to observe the (D)TLS profile parameters in 312 the (D)TLS handshake to permit intended use and to block malicious 313 behavior. This module uses the cryptographic types defined in 314 [I-D.ietf-netconf-crypto-types]. See [RFC7925] for (D)TLS 1.2 and 315 [I-D.ietf-uta-tls13-iot-profile] for DTLS 1.3 recommendations related 316 to IoT devices, and [RFC7525] for additional (D)TLS 1.2 317 recommendations. 319 A companion YANG module is defined to include a collection of (D)TLS 320 parameters and (D)TLS versions maintained by IANA: "iana-tls-profile" 321 (Section 5.3). 323 The (D)TLS parameters in each (D)TLS profile include the following: 325 o Profile name 327 o (D)TLS versions supported by the IoT device. 329 o List of supported cipher suites. For (D)TLS1.2, [RFC7925] 330 recommends AEAD ciphers for IoT devices. 332 o List of supported extension types 334 o List of trust anchor certificates used by the IoT device. If the 335 server certificate is signed by one of the trust anchors, the 336 middlebox continues with the connection as normal. Otherwise, the 337 middlebox will react as if the server certificate validation has 338 failed and takes appropriate action (e.g, block the (D)TLS 339 session). An IoT device can use a private trust anchor to 340 validate a server's certificate (e.g., the private trust anchor 341 can be preloaded at manufacturing time on the IoT device and the 342 IoT device fetches the firmware image from the Firmware server 343 whose certificate is signed by the private CA). This empowers the 344 middlebox to reject TLS sessions to servers that the IoT device 345 does not trust. 347 o List of SPKI pin set pre-configured on the client to validate 348 self-signed server certificates or raw public keys. A SPKI pin 349 set is a cryptographic digest to "pin" public key information in a 350 manner similar to HTTP Public Key Pinning (HPKP) [RFC7469]. If 351 SPKI pin set is present in the (D)TLS profile of a IoT device and 352 the server certificate does not pass the PKIX certification path 353 validation, the middlebox computes the SPKI Fingerprint for the 354 public key found in the server's certificate (or in the raw public 355 key, if the server provides that instead). If a computed 356 fingerprint exactly matches one of the SPKI pin sets in the (D)TLS 357 profile, the middlebox continues with the connection as normal. 358 Otherwise, the middlebox will act on the SPKI validation failure 359 and takes appropriate action. 361 o Cryptographic hash algorithm used to generate the SPKI pinsets 363 o List of pre-shared key exchange modes 365 o List of named groups (DHE or ECDHE) supported by the client 367 o List signature algorithms the client can validate in X.509 server 368 certificates 370 o List signature algorithms the client is willing to accept for 371 CertificateVerify message (Section 4.2.3 of [RFC8446]). For 372 example, a TLS client implementation can support different sets of 373 algorithms for certificates and in TLS to signal the capabilities 374 in "signature_algorithms_cert" and "signature_algorithms" 375 extensions. 377 o List of supported application protocols (e.g., h3, h2, http/1.1 378 etc.) 380 o List of certificate compression algorithms (defined in 381 [I-D.ietf-tls-certificate-compression]) 383 o List of the distinguished names [X501] of acceptable certificate 384 authorities, represented in DER-encoded format [X690] (defined in 385 Section 4.2.4 of [RFC8446]) 387 GREASE [RFC8701] sends random values on TLS parameters to ensure 388 future extensibility of TLS extensions. Similar random values might 389 be extended to other TLS parameters. Thus, the (D)TLS profile 390 parameters defined in the YANG module by this document MUST NOT 391 include the GREASE values for extension types, named groups, 392 signature algorithms, (D)TLS versions, pre-shared key exchange modes, 393 cipher suites and for any other TLS parameters defined in future 394 RFCs. 396 The (D)TLS profile does not include parameters like compression 397 methods for data compression, [RFC7525] recommends disabling TLS- 398 level compression to prevent compression-related attacks. In TLS 399 1.3, only the "null" compression method is allowed (Section 4.1.2 of 400 [RFC8446]). 402 Note: The TLS and DTLS IANA registries are available from 403 404 and . The values for all the parameters in the 406 YANG module excluding the are defined in the TLS and DTLS IANA 407 registries excluding the supported_tls_versions and 408 supported_dtls_versions parameters. The TLS and DTLS IANA registry 409 does not maintain (D)TLS version numbers. 411 5.1. Tree Structure of the (D)TLS profile Extension to the ACL YANG 412 Model 414 This document augments the "ietf-acl" ACL YANG module defined in 415 [RFC8519] for signaling the IoT device (D)TLS profile. This document 416 defines the YANG module "ietf-acl-tls", which has the following tree 417 structure: 419 module: ietf-acl-tls 420 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: 421 +--rw client-profile {match-on-tls-dtls}? 422 +--rw client-profile 423 +--rw tls-dtls-profiles* [profile-name] 424 +--rw profile-name string 425 +--rw supported-tls-versions* ianatp:tls-version 426 +--rw supported-dtls-versions* ianatp:dtls-version 427 +--rw cipher-suites* [cipher aead] 428 | +--rw cipher ianatp:cipher-algorithm 429 | +--rw aead ianatp:aead-algorithm 430 +--rw extension-types* 431 | ianatp:extension-type 432 +--rw acceptlist-ta-certs* 433 | ct:trust-anchor-cert-cms 434 +--rw SPKI 435 | +--rw SPKI-pin-sets* ianatp:SPKI-pin-set 436 | +--rw SPKI-hash-algorithm? iha:hash-algorithm-type 437 +--rw psk-key-exchange-modes* 438 | ianatp:psk-key-exchange-mode 439 | {tls-1-3 or dtls-1-3}? 440 +--rw supported-groups* 441 | ianatp:supported-group 442 +--rw signature-algorithms-cert* 443 | ianatp:signature-algorithm 444 | {tls-1-3 or dtls-1-3}? 445 +--rw signature-algorithms* 446 | ianatp:signature-algorithm 447 +--rw application-protocols* 448 | ianatp:application-protocol 449 +--rw cert-compression-algorithms* 450 | ianatp:cert-compression-algorithm 451 | {tls-1-3 or dtls-1-3}? 452 +--rw certificate_authorities* 453 ianatp:certificate_authority 454 {tls-1-3 or dtls-1-3}? 456 5.2. The (D)TLS profile Extension to the ACL YANG Model 458 file "ietf-acl-tls@2020-10-07.yang" 459 module ietf-acl-tls { 460 yang-version 1.1; 461 namespace "urn:ietf:params:xml:ns:yang:ietf-acl-tls"; 462 prefix ietf-acl-tls; 464 import iana-tls-profile { 465 prefix ianatp; 466 reference 467 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS 468 Profiles for IoT Devices"; 469 } 470 import ietf-crypto-types { 471 prefix ct; 472 reference 473 "RFC CCCC: Common YANG Data Types for Cryptography"; 474 } 475 import iana-hash-algs { 476 prefix iha; 477 reference 478 "RFC IIII: Common YANG Data Types for 479 Hash algorithms"; 480 } 481 import ietf-access-control-list { 482 prefix acl; 483 reference 484 "RFC 8519: YANG Data Model for Network Access 485 Control Lists (ACLs)"; 486 } 488 organization 489 "IETF OPSAWG (Operations and Management Area Working Group)"; 490 contact 491 "WG Web: 492 WG List: opsawg@ietf.org 494 Author: Konda, Tirumaleswar Reddy 495 TirumaleswarReddy_Konda@McAfee.com 496 "; 497 description 498 "This YANG moudle defines a component that augments the 499 IETF description of an access list to allow (D)TLS profile 500 as matching criteria. 502 Copyright (c) 2020 IETF Trust and the persons identified as 503 authors of the code. All rights reserved. 505 Redistribution and use in source and binary forms, with or 506 without modification, is permitted pursuant to, and subject 507 to the license terms contained in, the Simplified BSD License 508 set forth in Section 4.c of the IETF Trust's Legal Provisions 509 Relating to IETF Documents 510 (http://trustee.ietf.org/license-info). 512 This version of this YANG module is part of RFC XXXX; see 513 the RFC itself for full legal notices."; 515 revision 2020-10-07 { 516 description 517 "Initial revision"; 518 reference 519 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS 520 Profiles for IoT Devices"; 521 } 523 feature tls-1-2 { 524 description 525 "TLS Protocol Version 1.2 is supported."; 526 reference 527 "RFC 5246: The Transport Layer Security (TLS) Protocol 528 Version 1.2"; 529 } 531 feature tls-1-3 { 532 description 533 "TLS Protocol Version 1.3 is supported."; 534 reference 535 "RFC 8446: The Transport Layer Security (TLS) Protocol 536 Version 1.3"; 537 } 539 feature dtls-1-2 { 540 description 541 "DTLS Protocol Version 1.2 is supported."; 542 reference 543 "RFC 6346: Datagram Transport Layer Security Version 1.2"; 544 } 546 feature dtls-1-3 { 547 description 548 "DTLS Protocol Version 1.3 is supported."; 549 reference 550 "draft-ietf-tls-dtls13: Datagram Transport Layer Security 1.3"; 551 } 553 feature match-on-tls-dtls { 554 description 555 "The networking device can support matching on (D)TLS parameters."; 556 } 558 augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" { 559 if-feature "match-on-tls-dtls"; 560 description 561 "(D)TLS specific matches."; 562 container client-profile { 563 description 564 "A grouping for (D)TLS profiles."; 565 container client-profile { 566 description 567 "A grouping for DTLS profiles."; 568 list tls-dtls-profiles { 569 key "profile-name"; 570 description 571 "A list of (D)TLS version profiles supported by the client."; 572 leaf profile-name { 573 type string { 574 length "1..64"; 575 } 576 description 577 "The name of (D)TLS profile; space and special 578 characters are not allowed."; 579 } 580 leaf-list supported-tls-versions { 581 type ianatp:tls-version; 582 description 583 "TLS versions supported by the client"; 584 } 585 leaf-list supported-dtls-versions { 586 type ianatp:dtls-version; 587 description 588 "DTLS versions supported by the client"; 589 } 590 list cipher-suites { 591 key "cipher aead"; 592 leaf cipher { 593 type ianatp:cipher-algorithm; 594 description 595 "Cipher"; 596 } 597 leaf aead { 598 type ianatp:aead-algorithm; 599 description 600 "AEAD"; 601 } 602 description 603 "Cipher Suites"; 604 } 605 leaf-list extension-types { 606 type ianatp:extension-type; 607 description 608 "Extension Types"; 609 } 610 leaf-list acceptlist-ta-certs { 611 type ct:trust-anchor-cert-cms; 612 description 613 "A list of trust anchor certificates used by the client."; 614 } 615 container SPKI { 616 description 617 "A grouping for SPKI."; 618 leaf-list SPKI-pin-sets { 619 type ianatp:SPKI-pin-set; 620 description 621 "A list of SPKI pin sets pre-configured on the client 622 to validate self-signed server certificate or 623 raw public key."; 624 } 625 leaf SPKI-hash-algorithm { 626 type iha:hash-algorithm-type; 627 description 628 "cryptographic hash algorithm used to generate the 629 SPKI pinset."; 630 } 631 } 632 leaf-list psk-key-exchange-modes { 633 if-feature "tls-1-3 or dtls-1-3"; 634 type ianatp:psk-key-exchange-mode; 635 description 636 "pre-shared key exchange modes"; 637 } 638 leaf-list supported-groups { 639 type ianatp:supported-group; 640 description 641 "A list of named groups supported by the client."; 642 } 643 leaf-list signature-algorithms-cert { 644 if-feature "tls-1-3 or dtls-1-3"; 645 type ianatp:signature-algorithm; 646 description 647 "A list signature algorithms the client can validate 648 in X.509 certificates."; 649 } 650 leaf-list signature-algorithms { 651 type ianatp:signature-algorithm; 652 description 653 "A list signature algorithms the client can validate 654 in the CertificateVerify message."; 655 } 656 leaf-list application-protocols { 657 type ianatp:application-protocol; 658 description 659 "A list application protocols supported by the client"; 660 } 661 leaf-list cert-compression-algorithms { 662 if-feature "tls-1-3 or dtls-1-3"; 663 type ianatp:cert-compression-algorithm; 664 description 665 "A list certificate compression algorithms 666 supported by the client"; 667 } 668 leaf-list certificate_authorities { 669 if-feature "tls-1-3 or dtls-1-3"; 670 type ianatp:certificate_authority; 671 description 672 "A list of the distinguished names of certificate authorities 673 acceptable to the client"; 674 } 675 } 676 } 677 } 678 } 679 } 680 682 5.3. IANA (D)TLS profile YANG Module 684 file "iana-tls-profile@2020-10-07.yang" 686 module iana-tls-profile { 687 yang-version 1.1; 688 namespace "urn:ietf:params:xml:ns:yang:iana-tls-profile"; 689 prefix ianatp; 691 organization 692 "IANA"; 693 contact 694 " Internet Assigned Numbers Authority 696 Postal: ICANN 697 12025 Waterfront Drive, Suite 300 698 Los Angeles, CA 90094-2536 699 United States 701 Tel: +1 310 301 5800 702 E-Mail: iana@iana.org>"; 703 description 704 "This module contains YANG definition for the (D)TLS profile. 706 Copyright (c) 2020 IETF Trust and the persons identified as 707 authors of the code. All rights reserved. 709 Redistribution and use in source and binary forms, with or 710 without modification, is permitted pursuant to, and subject 711 to the license terms contained in, the Simplified BSD License 712 set forth in Section 4.c of the IETF Trust's Legal Provisions 713 Relating to IETF Documents 714 (http://trustee.ietf.org/license-info). 716 This version of this YANG module is part of RFC XXXX; see 717 the RFC itself for full legal notices."; 719 revision 2020-10-07 { 720 description 721 "Initial revision"; 722 reference 723 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS Profiles 724 for IoT Devices"; 725 } 727 typedef extension-type { 728 type uint16; 729 description 730 "Extension type"; 731 } 733 typedef supported-group { 734 type uint16; 735 description 736 "Named group (DHE or ECDHE)"; 737 } 739 typedef SPKI-pin-set { 740 type binary; 741 description 742 "Subject Public Key Info pin set"; 743 } 745 typedef signature-algorithm { 746 type uint16; 747 description 748 "Signature algorithm"; 749 } 751 typedef psk-key-exchange-mode { 752 type uint8; 753 description 754 "pre-shared key exchange mode"; 756 } 758 typedef application-protocol { 759 type string; 760 description 761 "application protocol"; 762 } 764 typedef cert-compression-algorithm { 765 type uint16; 766 description 767 "certificate compression algorithm"; 768 } 770 typedef certificate_authority { 771 type string; 772 description 773 "Distinguished Name of Certificate authority"; 774 } 776 typedef cipher-algorithm { 777 type uint8; 778 description 779 "Cipher Algorithm"; 780 } 782 typedef aead-algorithm { 783 type uint8; 784 description 785 "AEAD Algorithm"; 786 } 788 typedef tls-version { 789 type enumeration { 790 enum tls-1.2 { 791 value 1; 792 description 793 "TLS Protocol Version 1.2."; 794 reference 795 "RFC 5246: The Transport Layer Security (TLS) Protocol 796 Version 1.2"; 797 } 798 enum tls-1.3 { 799 value 2; 800 description 801 "TLS Protocol Version 1.3."; 802 reference 803 "RFC 8446: The Transport Layer Security (TLS) Protocol 804 Version 1.3"; 805 } 806 } 807 description 808 "Indicates the TLS version."; 809 } 811 typedef dtls-version { 812 type enumeration { 813 enum dtls-1.2 { 814 value 1; 815 description 816 "DTLS Protocol Version 1.2."; 817 reference 818 "RFC 6346: Datagram Transport Layer Security 1.2"; 819 } 820 enum dtls-1.3 { 821 value 2; 822 description 823 "DTLS Protocol Version 1.3."; 824 reference 825 "RFC DDDD: Datagram Transport Layer Security 1.3"; 826 } 827 } 828 description 829 "Indicates the DTLS version."; 830 } 831 } 832 834 5.4. MUD (D)TLS Profile Extension 836 This document augments the "ietf-mud" MUD YANG module to indicate 837 whether the device supports (D)TLS profile. If the "ietf-mud-tls" 838 extension is supported by the device, MUD file is assumed to 839 implement the "match-on-tls-dtls" ACL model feature defined in this 840 specification. Furthermore, only "accept" or "drop" actions SHOULD 841 be included with the (D)TLS profile similar to the actions allowed in 842 Section 2 of [RFC8520]. 844 This document defines the YANG module "ietf-mud-tls", which has the 845 following tree structure: 847 module: ietf-mud-tls 848 augment /ietf-mud:mud: 849 +--rw is-tls-dtls-profile-supported? boolean 851 The model is defined as follows: 853 file "iana-tls-mud@2020-10-20.yang" 855 module ietf-mud-tls { 856 yang-version 1.1; 857 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-tls"; 858 prefix ietf-mud-tls; 860 import ietf-mud { 861 prefix ietf-mud; 862 } 864 organization 865 "IETF OPSAWG (Operations and Management Area Working Group)"; 866 contact 867 "WG Web: 868 WG List: opsawg@ietf.org 870 Author: Konda, Tirumaleswar Reddy 871 TirumaleswarReddy_Konda@McAfee.com 873 "; 874 description 875 "Extension to a MUD module to indicate (D)TLS 876 profile support."; 878 revision 2020-10-19 { 879 description 880 "Initial revision."; 881 reference 882 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS 883 Profiles for IoT Devices"; 884 } 886 augment "/ietf-mud:mud" { 887 description 888 "This adds a extension for a manufacturer 889 to indicate whether (D)TLS profile is 890 is supported by a device."; 891 leaf is-tls-dtls-profile-supported { 892 type boolean; 893 description 894 "This value will equal 'true' if a device supports 895 (D)TLS profile."; 896 } 897 } 898 } 899 901 6. Processing of the MUD (D)TLS Profile 903 The following text outlines the rules for a network security service 904 (e.g., firewall) to follow to process the MUD (D)TLS Profile: 906 o If the (D)TLS parameter observed in a (D)TLS session is not 907 specified in the MUD (D)TLS profile and the parameter is 908 recognized by the firewall, it can identify unexpected (D)TLS 909 usage, which can indicate the presence of unauthorized software or 910 malware on an endpoint. The firewall can take several actions 911 like block the (D)TLS session or raise an alert to quarantine and 912 remediate the compromised device. For example, if the cipher 913 suite TLS_RSA_WITH_AES_128_CBC_SHA in the ClientHello message is 914 not specified in the MUD (D)TLS profile and the cipher suite is 915 recognized by the firewall, it can identify unexpected TLS usage. 917 o If the (D)TLS parameter observed in a (D)TLS session is not 918 specified in the MUD (D)TLS profile and the (D)TLS parameter is 919 not recognized by the firewall, it can ignore the unrecognized 920 parameter and the correct behavior is not to block the (D)TLS 921 session. The behaviour is functionally equivalent to the 922 description in Section 9.3 of [RFC8446] to ignore all unrecognized 923 cipher suites, extensions, and other parameters. For example, if 924 the cipher suite TLS_CHACHA20_POLY1305_SHA256 in the ClientHello 925 message is not specified in the MUD (D)TLS profile and the cipher 926 suite is not recognized by the firewall, it can ignore the 927 unrecognized cipher suite. 929 o Deployments update at different rates, so an updated MUD (D)TLS 930 profile may support newer parameters. If the firewall does not 931 recognize the newer parameters, an alert should be triggered to 932 the firewall vendor and the IoT device owner or administrator. A 933 firewall must be readily updatable, so that when ossification 934 problems are discovered, they can be addressed quickly. Most 935 importantly, if the firewall is not readily updatable, its 936 efficacy to identify emerging malware will decrease with time. 937 For example, if the cipher suite TLS_AES_128_CCM_8_SHA256 in the 938 ClientHello message is specified in the MUD (D)TLS profile and the 939 cipher suite is not recognized by the firewall, an alert will be 940 triggered. 942 7. MUD File Example 944 The example below contains (D)TLS profile parameters for a IoT device 945 used to reach servers listening on port 443 using TCP transport. 946 JSON encoding of YANG modelled data [RFC7951] is used to illustrate 947 the example. 949 { 950 "ietf-mud:mud": { 951 "mud-version": 1, 952 "mud-url": "https://example.com/IoTDevice", 953 "last-update": "2019-18-06T03:56:40.105+10:00", 954 "cache-validity": 100, 955 "extensions": [ 956 "ietf-mud-tls" 957 ], 958 "ietf-mud-tls:is-tls-dtls-profile-supported": "true", 959 "is-supported": true, 960 "systeminfo": "IoT device name", 961 "from-device-policy": { 962 "access-lists": { 963 "access-list": [ 964 { 965 "name": "mud-7500-profile" 966 } 967 ] 968 } 969 }, 970 "ietf-access-control-list:acls": { 971 "acl": [ 972 { 973 "name": "mud-7500-profile", 974 "type": "ipv6-acl-type", 975 "aces": { 976 "ace": [ 977 { 978 "name": "cl0-frdev", 979 "matches": { 980 "ipv6": { 981 "protocol": 6 982 }, 983 "tcp": { 984 "ietf-mud:direction-initiated": "from-device", 985 "destination-port": { 986 "operator": "eq", 987 "port": 443 988 } 989 }, 990 "ietf-acl-tls:client-profile" : { 991 "tls-dtls-profiles" : [ 992 { 993 "supported-tls-versions" : ["tls-1.3"], 994 "cipher-suites" : [ 995 { 996 "cipher": 19, 997 "aead": 1 998 }, 999 { 1000 "cipher": 19, 1001 "aead": 2 1002 } 1003 ], 1004 "extension-types" : [10,11,13,16,24], 1005 "supported-groups" : [29] 1006 } 1007 ] 1008 }, 1009 "actions": { 1010 "forwarding": "accept" 1011 } 1012 } 1013 } 1014 ] 1015 } 1016 } 1017 ] 1018 } 1019 } 1020 } 1022 The following illustrates the example scenarios for processing the 1023 above profile: 1025 o If the extension type "encrypt_then_mac" (code point 22) [RFC7366] 1026 in the ClientHello message is recognized by the firewall, it can 1027 identify unexpected TLS usage. 1029 o If the extension type "token_binding" (code point 24) [RFC8472] in 1030 the ClientHello message is not recognized by the firewall, it can 1031 ignore the unrecognized extension. Because the extension type 1032 token_binding is specified in the profile, an alert will be 1033 triggered to the firewall vendor and the IoT device owner or 1034 administrator to notify the firewall is not up to date. 1036 8. Security Considerations 1038 Security considerations in [RFC8520] need to be taken into 1039 consideration. Although it is challenging for a malware to mimic the 1040 TLS behavior of various IoT device types and IoT device models from 1041 several manufacturers, malicious agents have a very low probability 1042 of using the same (D)TLS profile parameters as legitimate agents on 1043 the IoT device to evade detection. Network security services should 1044 also rely on contextual network data to detect false negatives. In 1045 order to detect such malicious flows, anomaly detection (deep 1046 learning techniques on network data) can be used to detect malicious 1047 agents using the same (D)TLS profile parameters as legitimate agent 1048 on the IoT device. In anomaly detection, the main idea is to 1049 maintain rigorous learning of "normal" behavior and where an 1050 "anomaly" (or an attack) is identified and categorized based on the 1051 knowledge about the normal behavior and a deviation from this normal 1052 behavior. 1054 9. Privacy Considerations 1056 Privacy considerations discussed in Section 16 of [RFC8520] to not 1057 reveal the MUD URL to an atacker need to be taken into consideration. 1058 The MUD URL can be stored in Trusted Execution Environment (TEE) for 1059 secure operation, enhanced data security, and prevent exposure to 1060 unauthorized software. 1062 The middlebox acting as a (D)TLS proxy must immediately delete the 1063 decrypted data upon completing any necessary inspection functions. 1064 TLS proxy potentially has access to a user's PII (Personally 1065 identifiable information) and PHI (Protected Health Information). 1066 The TLS proxy must not store, process or modify PII data. For 1067 example, IT administrator can configure the middlebox to bypass 1068 payload inspection for a connection destined to a specific service 1069 due to privacy compliance requirements. In addition, mechanisms 1070 based on object security can be used by IoT devices to enable end-to- 1071 end security and the middlebox will not have any access to the packet 1072 data. For example, Object Security for Constrained RESTful 1073 Environments (OSCORE) [RFC8613] is a proposal that protects CoAP 1074 messages by wrapping them in the COSE format [RFC8152]. 1076 10. IANA Considerations 1078 10.1. (D)TLS Profile YANG Modules 1080 Each normative YANG module MUST be registered in both the "IETF XML 1081 Registry" [RFC3688] and the "YANG Module Names" registry [RFC6020]. 1083 This document requests IANA to register the following URIs in the 1084 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 1086 URI: urn:ietf:params:xml:ns:yang:iana-tls-profile 1087 Registrant Contact: The IESG. 1088 XML: N/A; the requested URI is an XML namespace. 1090 URI: urn:ietf:params:xml:ns:yang:ietf-acl-tls 1091 Registrant Contact: The IESG. 1092 XML: N/A; the requested URI is an XML namespace. 1094 URI: urn:ietf:params:xml:ns:yang:ietf-mud-tls 1095 Registrant Contact: The IESG. 1096 XML: N/A; the requested URI is an XML namespace. 1098 IANA is requested to create an IANA-maintained YANG Module called 1099 "iana-tls-profile", based on the contents of Section 5.3, which will 1100 allow for new (D)TLS parameters and (D)TLS versions to be added to 1101 "client-profile". The registration procedure will be Expert Review, 1102 as defined by [RFC8126]. 1104 This document requests IANA to register the following YANG modules in 1105 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1106 Parameters" registry. 1108 name: iana-tls-profile 1109 namespace: urn:ietf:params:xml:ns:yang:iana-tls-profile 1110 maintained by IANA: Y 1111 prefix: ianatp 1112 reference: RFC XXXX 1114 name: ietf-acl-tls 1115 namespace: urn:ietf:params:xml:ns:yang:ietf-acl-tls 1116 maintained by IANA: N 1117 prefix: ietf-acl-tls 1118 reference: RFC XXXX 1120 name: ietf-mud-tls 1121 namespace: urn:ietf:params:xml:ns:yang:ietf-mud-tls 1122 maintained by IANA: N 1123 prefix: ietf-mud-tls 1124 reference: RFC XXXX 1126 IANA is requested to create an the initial version of the IANA- 1127 maintained YANG Module called "iana-tls-profile", based on the 1128 contents of Section 5.3, which will allow for new (D)TLS parameters 1129 and (D)TLS versions to be added. IANA is requested to add this note: 1131 o tls-version and dtls-version values must not be directly added to 1132 the iana-tls-profile YANG module. They must instead be 1133 respectively added to the "TLS Version Codes", and "DTLS Version 1134 Codes" registries. 1136 o (D)TLS parameters must not be directly added to the iana-tls- 1137 profile YANG module. They must instead be added to the "(D)TLS 1138 Parameters" registry. 1140 When a 'tls-version' or 'dtls-version' value is respectively added to 1141 the "TLS Version Codes" or "DTLS Version Codes" registry, a new 1142 "enum" statement must be added to the iana-tls-profile YANG module. 1143 The following "enum" statement, and substatements thereof, should be 1144 defined: 1146 "enum": Replicates the label from the registry. 1148 "value": Contains the IANA-assigned value corresponding to the 1149 'tls-version' or 'dtls-version'. 1151 "description": Replicates the description from the registry. 1153 "reference": Replicates the reference from the registry and adds 1154 the title of the document. 1156 When a (D)TLS parameter is added to "(D)TLS Parameters" registry, a 1157 new "type" statement must be added to the iana-tls-profile YANG 1158 module. The following "type" statement, and substatements thereof, 1159 should be defined: 1161 "derived type": Replicates the parameter name from the registry. 1163 "built-in type": Contains the built-in YANG type. 1165 "description": Replicates the description from the registry. 1167 When the iana-tls-profile YANG module is updated, a new "revision" 1168 statement must be added in front of the existing revision statements. 1170 IANA is requested to add this note to "TLS Version Codes", "DTLS 1171 Version Codes", and "(D)TLS Parameters" registries: 1173 When this registry is modified, the YANG module iana-tls-profile 1174 must be updated as defined in [RFCXXXX]. 1176 The registration procedure for "ietf-acl-tls" YANG module will be 1177 Specification Required, as defined by [RFC8126]. 1179 10.2. TLS Version registry 1181 IANA is requested to create a new subregistry titled "TLS Version 1182 Codes". Codes in this registry are used as valid values of 'tls- 1183 version' parameter. Further assignments are to be made through 1184 Expert Review [RFC8126]. 1186 +-----------+-------------+--------------------------+-----------+ 1187 | Value | Label | Description | Reference | 1188 | | | | | 1189 | | | | | 1190 +-----------+-------------+--------------------------+-----------+ 1191 | 1 | tls-1.2 | TLS Protocol Version 1.2 | [RFC5246] | 1192 +----------------------------------------------------+-----------+ 1193 | 2 | tls-1.3 | TLS Protocol Version 1.3 | [RFC8446] | 1194 +----------------------------+-----------------------+-----------+ 1196 10.3. DTLS version registry 1198 IANA is requested to create a new subregistry titled "DTLS Version 1199 Codes". Codes in this registry are used as valid values of 'dtls- 1200 version' parameter. Further assignments are to be made through 1201 Expert Review [RFC8126]. 1203 +-----------+-------------+---------------------------+-------------------------+ 1204 | Value | Label | Description | Reference | 1205 | | | | | 1206 | | | | | 1207 +-----------+-------------+---------------------------+-------------------------+ 1208 | 1 | dtls-1.2 | DTLS Protocol Version 1.2 | [RFC6346] | 1209 +-----------------------------------------------------+-------------------------+ 1210 | 2 | dtls-1.3 | DTLS Protocol Version 1.3 | [draft-ietf-tls-dtls13] | 1211 +----------------------------+------------------------+-------------------------+ 1213 10.4. (D)TLS Parameters registry 1215 IANA is requested to create a new subregistry titled "(D)TLS 1216 parameters". The values for all the (D)TLS parameters in the 1217 registry are defined in the TLS and DTLS IANA registries 1218 ( 1219 and ) excluding the supported_tls_versions and 1221 supported_dtls_versions parameters. Further assignments are to be 1222 made through Expert Review [RFC8126]. The registry is initially 1223 populated with the following values: 1225 +----------------------------+-------------+--------+---------------------------------------------+ 1226 | Parameter Name | YANG | JSON | | 1227 | | Type | Type | Description | 1228 | | | | | 1229 +----------------------------+-------------+--------+---------------------------------------------+ 1230 | extension-type | uint16 | Number | Extension type | 1231 +----------------------------+-------------+--------+---------------------------------------------+ 1232 | supported-group | uint16 | Number | Named group (DHE or ECDHE) | 1233 +----------------------------+-------------+--------+---------------------------------------------+ 1234 | SPKI-pin-set | binary | String | Subject Public Key Info pin set | 1235 +----------------------------+-------------+--------+---------------------------------------------+ 1236 | signature-algorithm | uint16 | Number | Signature algorithm | 1237 +----------------------------+-------------+--------+---------------------------------------------+ 1238 | psk-key-exchange-mode | uint8 | Number | pre-shared key exchange mode | 1239 +----------------------------+-------------+--------+---------------------------------------------+ 1240 | application-protocol | string | String | application protocol | 1241 +----------------------------+-------------+--------+---------------------------------------------+ 1242 | cert-compression-algorithm | uint16 | Number | certificate compression algorithm | 1243 +----------------------------+-------------+--------+---------------------------------------------+ 1244 | certificate_authority | string | String | Distinguished Name of Certificate authority | 1245 +----------------------------+-------------+--------+---------------------------------------------+ 1246 | cipher-algorithm | uint8 | Number | Cipher Algorithm | 1247 +----------------------------+-------------+--------+---------------------------------------------+ 1248 | aead-algorithm | uint8 | Number | AEAD Algorithm | 1249 +----------------------------+-------------+--------+---------------------------------------------+ 1250 | tls-version | enumeration | String | TLS version | 1251 +----------------------------+-------------+--------+---------------------------------------------+ 1252 | dtls-version | enumeration | String | DTLS version | 1253 +----------------------------+-------------+--------+---------------------------------------------+ 1255 10.5. MUD Extensions registry 1257 IANA is requested to create a new MUD Extension Name "ietf-mud-tls" 1258 in the MUD Extensions IANA registry 1259 . 1261 11. Acknowledgments 1263 Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson, 1264 Piyush Joshi, Eliot Lear, Harsha Joshi, Qin Wu, Mohamed Boucadair, 1265 Ben Schwartz, Eric Rescorla, Panwei William, Nick Lamb and Nick 1266 Harper for the discussion and comments. 1268 12. References 1270 12.1. Normative References 1272 [I-D.ietf-netconf-crypto-types] 1273 Watsen, K., "YANG Data Types and Groupings for 1274 Cryptography", draft-ietf-netconf-crypto-types-18 (work in 1275 progress), August 2020. 1277 [I-D.ietf-tls-certificate-compression] 1278 Ghedini, A. and V. Vasiliev, "TLS Certificate 1279 Compression", draft-ietf-tls-certificate-compression-10 1280 (work in progress), January 2020. 1282 [I-D.ietf-tls-dtls13] 1283 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1284 Datagram Transport Layer Security (DTLS) Protocol Version 1285 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1286 2020. 1288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1289 Requirement Levels", BCP 14, RFC 2119, 1290 DOI 10.17487/RFC2119, March 1997, 1291 . 1293 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1294 DOI 10.17487/RFC3688, January 2004, 1295 . 1297 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1298 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1299 January 2012, . 1301 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1302 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1303 . 1305 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1306 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1307 May 2017, . 1309 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1310 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1311 . 1313 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1314 "YANG Data Model for Network Access Control Lists (ACLs)", 1315 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1316 . 1318 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 1319 Sustain Extensibility (GREASE) to TLS Extensibility", 1320 RFC 8701, DOI 10.17487/RFC8701, January 2020, 1321 . 1323 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 1324 Specification of Basic Encoding Rules (BER), Canonical 1325 Encoding Rules (CER) and Distinguished Encoding Rules 1326 (DER)", ISO/IEC 8825-1:2002, 2002. 1328 12.2. Informative References 1330 [clear-as-mud] 1331 "Clear as MUD: Generating, Validating and Applying IoT 1332 Behaviorial Profiles", October 2019, 1333 . 1335 [cryto-vulnerability] 1336 Perez, B., "Exploiting the Windows CryptoAPI 1337 Vulnerability", January 2020, 1338 . 1341 [I-D.ietf-tls-esni] 1342 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1343 Encrypted Client Hello", draft-ietf-tls-esni-07 (work in 1344 progress), June 2020. 1346 [I-D.ietf-uta-tls13-iot-profile] 1347 Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for 1348 the Internet of Things", draft-ietf-uta-tls13-iot- 1349 profile-00 (work in progress), June 2020. 1351 [I-D.reddy-add-enterprise] 1352 Reddy.K, T. and D. Wing, "DNS-over-HTTPS and DNS-over-TLS 1353 Server Deployment Considerations for Enterprise Networks", 1354 draft-reddy-add-enterprise-00 (work in progress), June 1355 2020. 1357 [malware] Anderson, B., Paul, S., and D. McGrew, "Deciphering 1358 Malware's use of TLS (without Decryption)", July 2016, 1359 . 1361 [malware-doh] 1362 Cimpanu, C., "First-ever malware strain spotted abusing 1363 new DoH (DNS over HTTPS) protocol", July 2019, 1364 . 1367 [malware-tls] 1368 Anderson, B. and D. McGrew, "TLS Beyond the Browser: 1369 Combining End Host and Network Data to Understand 1370 Application Behavior", October 2019, 1371 . 1373 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1374 the Network Configuration Protocol (NETCONF)", RFC 6020, 1375 DOI 10.17487/RFC6020, October 2010, 1376 . 1378 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1379 Extensions: Extension Definitions", RFC 6066, 1380 DOI 10.17487/RFC6066, January 2011, 1381 . 1383 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1384 "Transport Layer Security (TLS) Application-Layer Protocol 1385 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1386 July 2014, . 1388 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 1389 Security (TLS) and Datagram Transport Layer Security 1390 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 1391 . 1393 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1394 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1395 2015, . 1397 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1398 "Recommendations for Secure Use of Transport Layer 1399 Security (TLS) and Datagram Transport Layer Security 1400 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1401 2015, . 1403 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1404 Security (TLS) / Datagram Transport Layer Security (DTLS) 1405 Profiles for the Internet of Things", RFC 7925, 1406 DOI 10.17487/RFC7925, July 2016, 1407 . 1409 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1410 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1411 . 1413 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1414 Writing an IANA Considerations Section in RFCs", BCP 26, 1415 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1416 . 1418 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1419 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1420 . 1422 [RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport 1423 Layer Security (TLS) Extension for Token Binding Protocol 1424 Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 1425 2018, . 1427 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1428 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1429 . 1431 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1432 Description Specification", RFC 8520, 1433 DOI 10.17487/RFC8520, March 2019, 1434 . 1436 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1437 Things (IoT) Security: State of the Art and Challenges", 1438 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1439 . 1441 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1442 "Object Security for Constrained RESTful Environments 1443 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1444 . 1446 [X501] "Information Technology - Open Systems Interconnection - 1447 The Directory: Models", ITU-T X.501, 1993. 1449 Authors' Addresses 1450 Tirumaleswar Reddy 1451 McAfee, Inc. 1452 Embassy Golf Link Business Park 1453 Bangalore, Karnataka 560071 1454 India 1456 Email: kondtir@gmail.com 1458 Dan Wing 1459 Citrix Systems, Inc. 1460 4988 Great America Pkwy 1461 Santa Clara, CA 95054 1462 USA 1464 Email: danwing@gmail.com 1466 Blake Anderson 1467 Cisco Systems, Inc. 1468 170 West Tasman Dr 1469 San Jose, CA 95134 1470 USA 1472 Email: blake.anderson@cisco.com