idnits 2.17.1 draft-reddy-opsawg-mud-tls-04.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 5, 2020) is 1354 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: '31354' on line 709 -- Looks like a reference, but probably isn't: '4865' on line 709 -- Looks like a reference, but probably isn't: '4866' on line 709 -- Looks like a reference, but probably isn't: '4867' on line 709 -- Looks like a reference, but probably isn't: '10' on line 710 -- Looks like a reference, but probably isn't: '29' on line 711 == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-17 == 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 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-01 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSWG WG T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track D. Wing 5 Expires: February 6, 2021 Citrix 6 B. Anderson 7 Cisco 8 August 5, 2020 10 MUD (D)TLS profiles for IoT devices 11 draft-reddy-opsawg-mud-tls-04 13 Abstract 15 This memo extends Manufacturer Usage Description (MUD) to incorporate 16 (D)TLS profile parameters. This allows a network element to identify 17 unexpected (D)TLS usage, which can indicate the presence of 18 unauthorized software or malware on an endpoint. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 6, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Overview of MUD (D)TLS profiles for IoT devices . . . . . . . 5 57 4. (D)TLS 1.3 handshake . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Full (D)TLS 1.3 handshake inspection . . . . . . . . . . 6 59 4.2. Encrypted SNI . . . . . . . . . . . . . . . . . . . . . . 6 60 5. (D)TLS profile YANG module . . . . . . . . . . . . . . . . . 7 61 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 9 62 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 15 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 65 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 70 11.2. Informative References . . . . . . . . . . . . . . . . . 18 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 73 1. Introduction 75 Encryption is necessary to protect the privacy of end users using IoT 76 devices. In a network setting, TLS [RFC8446] and DTLS 77 [I-D.ietf-tls-dtls13] are the dominant protocols providing encryption 78 for IoT device traffic. Unfortunately, in conjunction with IoT 79 applications' rise of encryption, malware is also using encryption 80 which thwarts network-based analysis such as deep packet inspection 81 (DPI). Other mechanisms are needed to notice malware is running on 82 the IoT device. 84 Malware frequently uses its own libraries for its activities, and 85 those libraries are re-used much like any other software engineering 86 project. Research [malware] indicates there are observable 87 differences in how malware uses encryption compared with how non- 88 malware uses encryption. There are several interesting findings 89 specific to DTLS and TLS which were found common to malware: 91 o Older and weaker cryptographic parameters (e.g., 92 TLS_RSA_WITH_RC4_128_SHA). 94 o TLS SNI and server certificates are composed of subjects with 95 characteristics of a domain generation algorithm (DGA) (e.g., 96 www.33mhwt2j.net). 98 o Higher use of self-signed certificates compared with typical 99 legitimate software. 101 o Discrepancies in the server name indication (SNI) TLS extension in 102 the ClientHello message and the DNS names in the 103 SubjectAltName(SAN) X.509 extension in the server certificate 104 message. 106 o Discrepancies in the key exchange algorithm and the client public 107 key length in comparison with legitimate flows. As a reminder, 108 Client Key Exchange message has been removed from TLS 1.3. 110 o Lower diversity in TLS client advertised TLS extensions compared 111 to legitimate clients. 113 o Malware using privacy enhancing technologies like Tor, Psiphon and 114 Ultrasurf (see [malware-tls]) and, evasion techniques such as 115 ClientHello randomization to evade detection in order to continue 116 exploiting the end user. 118 o Malware using DNS-over-HTTPS [RFC8484] to avoid detection by 119 malware DNS filtering service ([malware-doh]). Malware agent may 120 not use the DNS-over-HTTPS server provided by the local network. 122 If observable (D)TLS profile parameters are used, the following 123 functions are possible which have a favorable impact on network 124 security: 126 o Permit intended DTLS or TLS use and block malicious DTLS or TLS 127 use. This is superior to the layer 3 and layer 4 ACLs of 128 Manufacturer Usage Description Specification (MUD) [RFC8520] which 129 are not suitable for broad communication patterns. 131 o Ensure TLS certificates are valid. Several TLS deployments have 132 been vulnerable to active Man-In-The-Middle (MITM) attacks because 133 of the lack of certificate validation or vulnerability in the 134 certificate validation function (see [cryto-vulnerability]). By 135 observing (D)TLS profile parameters, a network element can detect 136 when the TLS SNI mismatches the SubjectAltName and when the 137 server's certificate is invalid. In TLS 1.2, the ClientHello, 138 ServerHello and Certificate messages are all sent in clear-text, 139 however in TLS 1.3, the Certificate message is encrypted thereby 140 hiding the server identity from any intermediary. In TLS 1.3, the 141 middle-box needs to act as a TLS proxy to validate the server 142 certificate and to detect TLS SNI mismatch with the server 143 certificate. 145 o Support new communication patterns. An IoT device can learn a new 146 capability, and the new capability can change the way the IoT 147 device communicates with other devices located in the local 148 network and Internet. There would be an inaccurate policy if an 149 IoT device rapidly changes the IP addresses and domain names it 150 communicates with while the MUD ACLs were slower to update. In 151 such a case, observable (D)TLS profile parameters can be used to 152 permit intended use and to block malicious behaviour from the IoT 153 device. 155 This document extends MUD [RFC8520] to model observable (D)TLS 156 profile parameters. Using these (D)TLS profile parameters, an active 157 MUD-enforcing firewall can identify MUD non-compliant (D)TLS behavior 158 indicating outdated cryptography or malware. This detection can 159 prevent malware downloads, block access to malicious domains, enforce 160 use of strong ciphers, stop data exfiltration, etc. In addition, 161 organizations may have policies around acceptable ciphers and 162 certificates on the websites the IoT devices connect to. Examples 163 include no use of old and less secure versions of TLS, no use of 164 self-signed certificates, deny-list or accept-list of Certificate 165 Authorities, valid certificate expiration time, etc. These policies 166 can be enforced by observing the (D)TLS profile parameters. 167 Enterprise firewalls can use the IoT device's (D)TLS profile 168 parameters to identify legitimate flows by observing (D)TLS sessions, 169 and can make inferences to permit legitimate flows and to block 170 malicious or insecure flows. The proposed technique is also suitable 171 in deployments where decryption techniques are not ideal due to 172 privacy concerns, non-cooperating end-points and expense. 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in BCP 179 14 [RFC2119][RFC8174] when, and only when, they appear in all 180 capitals, as shown here. 182 "(D)TLS" is used for statements that apply to both Transport Layer 183 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 184 Specific terms are used for any statement that applies to either 185 protocol alone. 187 'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS. 189 3. Overview of MUD (D)TLS profiles for IoT devices 191 In Enterprise networks, protection and detection are typically done 192 both on end hosts and in the network. Host agents have deep 193 visibility on the devices where they are installed, whereas the 194 network has broader visibility. Installing host agents may not be a 195 viable option on IoT devices, and network-based security is an 196 efficient means to protect such IoT devices. (D)TLS profile 197 parameters of IoT device can be used by middle-boxes to detect and 198 block malware communication, while at the same time preserving the 199 privacy of legitimate uses of encryption. Middle-boxes need not 200 proxy (D)TLS but can passively observe the parameters of (D)TLS 201 handshakes from IoT devices and gain good visibility into TLS 1.0 to 202 1.2 parameters and partial visibility into TLS 1.3 parameters. 203 Malicious agents can try to use the (D)TLS profile parameters of 204 legitimate agents to evade detection, but it becomes a challenge to 205 mimic the behavior of various IoT device types and IoT device models 206 from several manufacturers. In other words, malware developers will 207 have to develop malicious agents per IoT device type, manufacturer 208 and model, infect the device with the tailored malware agent and will 209 have keep up with updates to the device's (D)TLS profile parameters 210 over time. Further, the malware's command and control server 211 certificates need to be signed by the same certifying authorities 212 trusted by the IoT devices. Typically, IoT devices have an 213 infrastructure that supports a rapid deployment of updates, and 214 malware agents will have a near-impossible task of similarly 215 deploying updates and continuing to mimic the TLS behavior of the IoT 216 device it has infected. 218 The compromised IoT devices are typically used for launching DDoS 219 attacks (Section 3 of [RFC8576]). Some of the DDoS attacks like 220 Slowloris and Transport Layer Security (TLS) re-negotiation can be 221 detected by observing the (D)TLS profile parameters. For example, 222 the victim's server certificate need not be signed by the same 223 certifying authorities trusted by the IoT device. 225 4. (D)TLS 1.3 handshake 227 In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since 228 all (D)TLS handshake messages excluding the ClientHello message are 229 encrypted. (D)TLS 1.3 has introduced new extensions in the handshake 230 record layers called Encrypted Extensions. Using these extensions 231 handshake messages will be encrypted and network devices (such as a 232 firewall) are incapable deciphering the handshake, thus cannot view 233 the server certificate. However, the ClientHello and ServerHello 234 still have some fields visible, such as the list of supported 235 versions, named groups, cipher suites, signature algorithms and 236 extensions in ClientHello and, chosen cipher in the ServerHello. For 237 instance, if the malware uses evasion techniques like ClientHello 238 randomization, the observable list of cipher suites and extensions 239 offered by the malware agent in the ClientHello message will not 240 match the list of cipher suites and extensions offered by the 241 legitimate client in the ClientHello message, and the middle-box can 242 block malicious flows without acting as a (D)TLS 1.3 proxy. 244 4.1. Full (D)TLS 1.3 handshake inspection 246 To obtain more visibility into negotiated TLS 1.3 parameters, a 247 middle-box can act as a (D)TLS 1.3 proxy. A middle-box can act as a 248 (D)TLS proxy for the IoT devices owned and managed by the IT team in 249 the Enterprise network and the (D)TLS proxy must meet the security 250 and privacy requirements of the organization. In other words, the 251 scope of middle-box acting as a (D)TLS proxy is restricted to 252 Enterprise network owning and managing the IoT devices. The middle- 253 box MUST follow the behaviour explained in Section 9.3 of [RFC8446] 254 to act as a compliant (D)TLS 1.3 proxy. 256 To function as a (D)TLS proxy the middle-box creates a signed 257 certificate using itself as a certificate authority. That 258 certificate authority has to be trusted by the (D)TLS client. The 259 IoT device needs to be configured with the middle-box's CA 260 certificate as Explicit Trust Anchor database entry to validate the 261 server certificate. The mechanism to configure the IoT device with 262 the middle-box's CA certificate is out of scope. The middle-box uses 263 the "supported_versions" TLS extension (defined in TLS 1.3 to 264 negotiate the supported TLS versions between client and server) to 265 determine the TLS version. During the (D)TLS handshake, If (D)TLS 266 version 1.3 is used, the middle-box ((D)TLS proxy) modifies the 267 certificate provided by the server and signs it with the private key 268 from the local CA certificate. The middle-box has visibility into 269 further exchanges between the IoT device and server which enables it 270 to inspect the (D)TLS 1.3 handshake, enforce the MUD (D)TLS profile 271 and can inspect subsequent network traffic. The IoT device uses the 272 Explicit Trust Anchor database to validate the server certificate. 274 4.2. Encrypted SNI 276 To increase privacy, encrypted SNI (ESNI, 277 [I-D.ietf-tls-sni-encryption]) prevents passive observation of the 278 TLS Server Name Indication extension. To effectively provide that 279 privacy protection, SNI encryption needs to be used in conjunction 280 with DNS encryption (e.g., DNS-over-TLS (DoT) [RFC7858] or DNS-over- 281 HTTPS (DoH) [RFC8484]). A middle-box (e.g., firewall) passively 282 inspecting an encrypted SNI (D)TLS handshake cannot observe the 283 encrypted SNI nor observe the encrypted DNS traffic. If an IoT 284 device is pre-configured to use public DoH/DoT servers, that middle- 285 box needs to act as a DoH/DoT proxy and replace the ECH configuration 286 in the "echconfig" SvcParamKey (Section 6.3 of 287 [I-D.ietf-dnsop-svcb-https]) with the middle box's ECH configuration. 288 Instead of an unappealing DoH/DoT proxy, the IoT device can be 289 bootstrapped to discover and authenticate DoH/DoT servers provided by 290 a local network by making use of one of the mechanisms described in 291 Section 4 of [I-D.reddy-add-enterprise]. The local DoH/DoT server 292 replaces the ECH configuration in the "echconfig" SvcParamKey with 293 the middle box's ECH configuration. 295 A common usage pattern for certain type of IoT devices (e.g., light 296 bulb) is for it to "call home" to a service that resides on the 297 public Internet, where that service is referenced through a domain 298 name (A or AAAA record). As discussed in Manufacturer Usage 299 Description Specification [RFC8520], because these devices tend to 300 require access to very few sites, all other access should be 301 considered suspect. If an IoT device is pre-configured to use public 302 DoH/DoT server, the MUD policy enforcement point is moved to that 303 public server, which cannot enforce the MUD policy based on domain 304 names (Section 8 of [RFC8520]). If the DNS query is not accessible 305 for inspection, it becomes quite difficult for the infrastructure to 306 suspect anything. Thus the use of a public DoH/DoT server is 307 incompatible with MUD in general. A local DoH/DoT server is 308 necessary to allow MUD policy enforcement on the local network. 310 5. (D)TLS profile YANG module 312 This document specifies a YANG module for representing (D)TLS 313 profile. The (D)TLS profile YANG module provides a method for 314 firewall to observe the (D)TLS profile parameters in the (D)TLS 315 handshake to permit intended use and to block malicious behavior. 316 This module uses the common YANG types defined in [RFC6991] , rules 317 defined in [RFC8519] and cryptographic types defined in 318 [I-D.ietf-netconf-crypto-types]. 320 The (D)TLS profiles and the parameters in each (D)TLS profile include 321 the following: 323 o Profile name 325 o (D)TLS version in ClientHello.legacy_version 327 o (D)TLS versions supported by the IoT device. As a reminder, 328 "supported_versions" extension defined in (D)TLS 1.3 is used by 329 the client to indicate which versions of (D)TLS it supports and a 330 client is considered to be attempting to negotiate (D)TLS 1.3 if 331 the ClientHello contains a "supported_versions" extension with 332 0x0304 contained in its body. 334 o If GREASE [RFC8701] (Generate Random Extensions And Sustain 335 Extensibility) values are offered by the client or not. 337 o List of supported symmetric encryption algorithms. TLS 1.3 338 defines five cipher suites (Appendix B.4 of [RFC8446]), but most 339 clients are continuing to offer TLS 1.2 compatible cipher suites 340 for backwards compatibility. 342 o List of supported compression methods for data compression. In 343 TLS 1.3, only the "null" compression method is allowed 344 (Section 4.1.2 of [RFC8446]). 346 o List of supported extension types 348 o List of trust anchor certificates used by the IoT device. If the 349 server certificate is signed by one of the trust anchors, the 350 middle-box continues with the connection as normal. Otherwise, 351 the middle-box will react as if the server certificate validation 352 has failed and takes appropriate action (e.g, block the (D)TLS 353 session). An IoT device can use a private trust anchor to 354 validate a server's certificate (e.g., the private trust anchor 355 can be preloaded at manufacturing time on the IoT device and the 356 IoT device fetches the firmware image from the Firmware server 357 whose certificate is signed by the private CA). 359 o List of SPKI pin set pre-configured on the client to validate 360 self-signed server certificates or raw public keys. A SPKI pin 361 set is a cryptographic digest to "pin" public key information in a 362 manner similar to HTTP Public Key Pinning (HPKP) [RFC7469]. If 363 SPKI pin set is present in the (D)TLS profile of a IoT device and 364 the server certificate does not pass the PKIX certification path 365 validation, the middle-box computes the SPKI Fingerprint for the 366 public key found in the server's certificate (or in the raw public 367 key, if the server provides that instead). If a computed 368 fingerprint exactly matches one of the SPKI pin sets in the (D)TLS 369 profile, the middle-box continues with the connection as normal. 370 Otherwise, the middle-box will act on the SPKI validation failure 371 and takes appropriate action. 373 o Cryptographic hash algorithm used to generate the SPKI pinsets 375 o List of pre-shared key exchange modes 377 o List of named groups (DHE or ECDHE) supported by the client 379 o List signature algorithms the client can validate in X.509 server 380 certificates 382 o List of supported application protocols (e.g., h3, h2, http/1.1 383 etc.) 385 o List of certificate compression algorithms (defined in 386 [I-D.ietf-tls-certificate-compression]) 388 o List of client key exchange algorithms and the client public key 389 lengths in versions prior to (D)TLS 1.3 391 The (D)TLS profile parameters include the GREASE values for extension 392 types, named groups, signature algorithms, (D)TLS versions, pre- 393 shared key exchange modes and cipher suites, but normalized to the 394 value 0x0a to preserve ordering information. Note that the GREASE 395 values are random but their positions are deterministic (Section 5 of 396 [RFC8701]) and peers will ignore these values and interoperate. 398 If the (D)TLS profile parameters are not observed in a (D)TLS session 399 from the IoT device, the default behaviour is to block the (D)TLS 400 session. 402 Note: The TLS and DTLS IANA registries are available from 403 . 405 5.1. Tree Structure 407 This document augments the "ietf-mud" MUD YANG module defined in 408 [RFC8520] for signaling the IoT device (D)TLS profile. This document 409 defines the YANG module "reddy-opsawg-mud-tls-profile", which has the 410 following tree structure: 412 module: reddy-opsawg-mud-tls-profile 413 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: 414 +--rw client-profile 415 +--rw tls-profiles* [profile-name] 416 +--rw profile-name string 417 +--rw protocol-version? uint16 418 +--rw supported_versions* uint16 419 +--rw grease_extension? boolean 420 +--rw encryption-algorithms* encryption-algorithm 421 +--rw compression-methods* compression-method 422 +--rw extension-types* extension-type 423 +--rw acceptlist-ta-certs* ct:trust-anchor-cert-cms 424 +--rw SPKI-pin-sets* SPKI-pin-set 425 +--rw SPKI-hash-algorithm? iha:hash-algorithm-type 426 +--rw psk-key-exchange-modes* psk-key-exchange-mode 427 +--rw supported-groups* supported-group 428 +--rw signature-algorithms* signature-algorithm 429 +--rw application-protocols* application-protocol 430 +--rw cert-compression-algorithms* cert-compression-algorithm 431 +--rw client-public-keys 432 +--rw key-exchange-algorithms* key-exchange-algorithm 433 +--rw client-public-key-lengths* client-public-key-length 435 5.2. YANG Module 437 module reddy-opsawg-mud-tls-profile { 438 yang-version 1.1; 439 namespace "urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile"; 440 prefix mud-tls-profile; 442 import ietf-crypto-types { 443 prefix ct; 444 reference "draft-ietf-netconf-crypto-types-01: 445 Common YANG Data Types for Cryptography"; 446 } 448 import iana-hash-algs { 449 prefix iha; 450 reference 451 "RFC XXXX: Common YANG Data Types for Hash algorithms"; 452 } 454 import ietf-access-control-list { 455 prefix acl; 456 reference 457 "RFC 8519: YANG Data Model for Network Access 458 Control Lists (ACLs)"; 460 } 462 organization 463 "IETF Operations and Management Area Working Group Working Group"; 464 contact 465 "Editor: Konda, Tirumaleswar Reddy 466 "; 468 description 469 "This module contains YANG definition for the IoT device 470 (D)TLS profile. 472 Copyright (c) 2019 IETF Trust and the persons identified as 473 authors of the code. All rights reserved. 475 Redistribution and use in source and binary forms, with or 476 without modification, is permitted pursuant to, and subject 477 to the license terms contained in, the Simplified BSD License 478 set forth in Section 4.c of the IETF Trust's Legal Provisions 479 Relating to IETF Documents 480 (http://trustee.ietf.org/license-info). 482 This version of this YANG module is part of RFC XXXX; see 483 the RFC itself for full legal notices."; 485 revision 2019-06-12 { 486 description 487 "Initial revision"; 488 } 490 typedef compression-method { 491 type uint8; 492 description "Compression method"; 493 } 495 typedef extension-type { 496 type uint16; 497 description "Extension type"; 498 } 500 typedef encryption-algorithm { 501 type uint16; 502 description "Encryption algorithm"; 503 } 505 typedef supported-group { 506 type uint16; 507 description "Named group (DHE or ECDHE)"; 509 } 511 typedef SPKI-pin-set { 512 type binary; 513 description "Subject Public Key Info pin set"; 514 } 516 typedef signature-algorithm { 517 type uint16; 518 description "Signature algorithm"; 519 } 521 typedef key-exchange-algorithm { 522 type uint8; 523 description "key exchange algorithm"; 524 } 526 typedef psk-key-exchange-mode { 527 type uint8; 528 description "pre-shared key exchange mode"; 529 } 531 typedef client-public-key-length { 532 type uint8; 533 description "client public key length"; 534 } 536 typedef application-protocol { 537 type string; 538 description "application protocol"; 539 } 541 typedef cert-compression-algorithm { 542 type uint8; 543 description "certificate compression algorithm"; 544 } 546 grouping client-profile { 547 description 548 "A grouping for (D)TLS profiles."; 549 container client-profile { 550 list tls-profiles { 551 key "profile-name"; 552 description 553 "A list of (D)TLS version profiles supported by the client."; 554 leaf profile-name { 555 type string { 556 length "1..64"; 558 } 559 description 560 "The name of (D)TLS profile; space and special 561 characters are not allowed."; 562 } 563 leaf protocol-version { 564 type uint16; 565 description "(D)TLS version in ClientHello.legacy_version"; 566 } 567 leaf-list supported_versions { 568 type uint16; 569 description 570 "TLS versions supported by the client indicated 571 in the supported_versions extension in (D)TLS 1.3."; 572 } 573 leaf grease_extension { 574 type boolean; 575 description 576 "If set to 'true', Grease extension values are offered by 577 the client."; 578 } 579 leaf-list encryption-algorithms { 580 type encryption-algorithm; 581 description "Encryption algorithms"; 582 } 583 leaf-list compression-methods { 584 type compression-method; 585 description "Compression methods"; 586 } 587 leaf-list extension-types { 588 type extension-type; 589 description "Extension Types"; 590 } 591 leaf-list acceptlist-ta-certs { 592 type ct:trust-anchor-cert-cms; 593 description 594 "A list of trust anchor certificates used by the client."; 595 } 596 leaf-list SPKI-pin-sets { 597 type SPKI-pin-set; 598 description 599 "A list of SPKI pin sets pre-configured on the client 600 to validate self-signed server certificate or 601 raw public key."; 602 } 603 leaf SPKI-hash-algorithm { 604 type iha:hash-algorithm-type; 605 description 606 "cryptographic hash algorithm used to generate the 607 SPKI pinset."; 608 } 609 leaf-list psk-key-exchange-modes { 610 type psk-key-exchange-mode; 611 description 612 "pre-shared key exchange modes"; 613 } 614 leaf-list supported-groups { 615 type supported-group; 616 description 617 "A list of named groups supported by the client."; 618 } 619 leaf-list signature-algorithms { 620 type signature-algorithm; 621 description 622 "A list signature algorithms the client can validate 623 in X.509 certificates."; 624 } 625 leaf-list application-protocols { 626 type application-protocol; 627 description 628 "A list application protocols supported by the client"; 629 } 630 leaf-list cert-compression-algorithms { 631 type cert-compression-algorithm; 632 description 633 "A list certificate compression algorithms 634 supported by the client"; 635 } 636 container client-public-keys { 637 leaf-list key-exchange-algorithms { 638 type key-exchange-algorithm; 639 description 640 "Key exchange algorithms supported by the client"; 641 } 642 leaf-list client-public-key-lengths { 643 type client-public-key-length; 644 description 645 "client public key lengths"; 646 } 647 } 648 } 649 } 650 } 651 augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" { 652 description 653 "MUD (D)TLS specific matches."; 655 uses client-profile; 656 } 657 } 659 6. MUD File Example 661 This example below contains (D)TLS profile parameters for a IoT 662 device used to reach servers listening on port 443 using TCP 663 transport. JSON encoding of YANG modelled data [RFC7951] is used to 664 illustrate the example. 666 { 667 "ietf-mud:mud": { 668 "mud-version": 1, 669 "mud-url": "https://example.com/IoTDevice", 670 "last-update": "2019-18-06T03:56:40.105+10:00", 671 "cache-validity": 100, 672 "is-supported": true, 673 "systeminfo": "IoT device name", 674 "from-device-policy": { 675 "access-lists": { 676 "access-list": [ 677 { 678 "name": "mud-7500-profile" 679 } 680 ] 681 } 682 }, 683 "ietf-access-control-list:acls": { 684 "acl": [ 685 { 686 "name": "mud-7500-profile", 687 "type": "ipv6-acl-type", 688 "aces": { 689 "ace": [ 690 { 691 "name": "cl0-frdev", 692 "matches": { 693 "ipv6": { 694 "protocol": 6 695 }, 696 "tcp": { 697 "ietf-mud:direction-initiated": "from-device", 698 "destination-port": { 699 "operator": "eq", 700 "port": 443 701 } 702 }, 703 "reddy-opsawg-mud-tls-profile:client-profile" : { 704 "tls-profiles" : [ 705 { 706 "protocol-version" : 771, 707 "supported_versions_ext" : "FALSE", 708 "encryption-algorithms" : 709 [31354, 4865, 4866, 4867], 710 "extension-types" : [10], 711 "supported-groups" : [29] 712 } 713 ] 714 }, 715 "actions": { 716 "forwarding": "accept" 717 } 718 } 719 } 720 ] 721 } 722 } 723 ] 724 } 725 } 726 } 728 7. Security Considerations 730 Security considerations in [RFC8520] need to be taken into 731 consideration. Although it is challenging for a malware to mimic the 732 TLS behavior of various IoT device types and IoT device models from 733 several manufacturers, malicious agents have a very low probabilty of 734 using the same (D)TLS profile parameters as legitimate agents on the 735 IoT device to evade detection. Network security services should also 736 rely on contextual network data to detect false negatives. In order 737 to detect such malicious flows, anomaly detection (deep learning 738 techniques on network data) can be used to detect malicious agents 739 using the same (D)TLS profile parameters as legitimate agent on the 740 IoT device. In anomaly detection, the main idea is to maintain 741 rigorous learning of "normal" behavior and where an "anomaly" (or an 742 attack) is identified and categorized based on the knowledge about 743 the normal behavior and a deviation from this normal behavior. 745 8. Privacy Considerations 747 The middle-box acting as a (D)TLS proxy must immediately delete the 748 decrypted data upon completing any necessary inspection functions. 749 TLS proxy potentially has access to a user's PII (Personally 750 identifiable information) and PHI (Protected Health Information). 752 The TLS proxy must not store, process or modify PII data. For 753 example, IT administrator can configure firewall to bypass payload 754 inspection for a connection destined to a specific service due to 755 privacy compliance requirements. 757 9. IANA Considerations 759 This document requests IANA to register the following URIs in the 760 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 762 URI: urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile 763 Registrant Contact: The IESG. 764 XML: N/A; the requested URI is an XML namespace. 766 10. Acknowledgments 768 Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson, 769 Piyush Joshi and Harsha Joshi for the discussion and comments. 771 11. References 773 11.1. Normative References 775 [I-D.ietf-netconf-crypto-types] 776 Watsen, K., "YANG Data Types and Groupings for 777 Cryptography", draft-ietf-netconf-crypto-types-17 (work in 778 progress), July 2020. 780 [I-D.ietf-tls-certificate-compression] 781 Ghedini, A. and V. Vasiliev, "TLS Certificate 782 Compression", draft-ietf-tls-certificate-compression-10 783 (work in progress), January 2020. 785 [I-D.ietf-tls-dtls13] 786 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 787 Datagram Transport Layer Security (DTLS) Protocol Version 788 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 789 2020. 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, 793 DOI 10.17487/RFC2119, March 1997, 794 . 796 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 797 DOI 10.17487/RFC3688, January 2004, 798 . 800 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 801 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 802 January 2012, . 804 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 805 RFC 6991, DOI 10.17487/RFC6991, July 2013, 806 . 808 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 809 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 810 May 2017, . 812 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 813 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 814 . 816 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 817 "YANG Data Model for Network Access Control Lists (ACLs)", 818 RFC 8519, DOI 10.17487/RFC8519, March 2019, 819 . 821 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 822 Sustain Extensibility (GREASE) to TLS Extensibility", 823 RFC 8701, DOI 10.17487/RFC8701, January 2020, 824 . 826 11.2. Informative References 828 [cryto-vulnerability] 829 Perez, B., "Exploiting the Windows CryptoAPI 830 Vulnerability", January 2020, 831 . 834 [I-D.ietf-dnsop-svcb-https] 835 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 836 and parameter specification via the DNS (DNS SVCB and 837 HTTPS RRs)", draft-ietf-dnsop-svcb-https-01 (work in 838 progress), July 2020. 840 [I-D.ietf-tls-sni-encryption] 841 Huitema, C. and E. Rescorla, "Issues and Requirements for 842 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-09 843 (work in progress), October 2019. 845 [I-D.reddy-add-enterprise] 846 Reddy.K, T. and D. Wing, "DNS-over-HTTPS and DNS-over-TLS 847 Server Deployment Considerations for Enterprise Networks", 848 draft-reddy-add-enterprise-00 (work in progress), June 849 2020. 851 [malware] Anderson, B., Paul, S., and D. McGrew, "Deciphering 852 Malware's use of TLS (without Decryption)", July 2016, 853 . 855 [malware-doh] 856 Cimpanu, C., "First-ever malware strain spotted abusing 857 new DoH (DNS over HTTPS) protocol", July 2019, 858 . 861 [malware-tls] 862 Anderson, B. and D. McGrew, "TLS Beyond the Browser: 863 Combining End Host and Network Data to Understand 864 Application Behavior", October 2019, 865 . 867 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 868 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 869 2015, . 871 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 872 and P. Hoffman, "Specification for DNS over Transport 873 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 874 2016, . 876 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 877 RFC 7951, DOI 10.17487/RFC7951, August 2016, 878 . 880 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 881 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 882 . 884 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 885 Description Specification", RFC 8520, 886 DOI 10.17487/RFC8520, March 2019, 887 . 889 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 890 Things (IoT) Security: State of the Art and Challenges", 891 RFC 8576, DOI 10.17487/RFC8576, April 2019, 892 . 894 Authors' Addresses 896 Tirumaleswar Reddy 897 McAfee, Inc. 898 Embassy Golf Link Business Park 899 Bangalore, Karnataka 560071 900 India 902 Email: kondtir@gmail.com 904 Dan Wing 905 Citrix Systems, Inc. 906 4988 Great America Pkwy 907 Santa Clara, CA 95054 908 USA 910 Email: danwing@gmail.com 912 Blake Anderson 913 Cisco Systems, Inc. 914 170 West Tasman Dr 915 San Jose, CA 95134 916 USA 918 Email: blake.anderson@cisco.com