idnits 2.17.1 draft-reddy-opsawg-mud-tls-05.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 2 instances of too long lines in the document, the longest one being 2 characters 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 30, 2020) is 1329 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 736 -- Looks like a reference, but probably isn't: '4865' on line 736 -- Looks like a reference, but probably isn't: '4866' on line 736 -- Looks like a reference, but probably isn't: '4867' on line 736 -- Looks like a reference, but probably isn't: '10' on line 737 -- Looks like a reference, but probably isn't: '29' on line 738 == 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 (-12) exists of draft-ietf-dnsop-svcb-https-01 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: March 3, 2021 Citrix 6 B. Anderson 7 Cisco 8 August 30, 2020 10 MUD (D)TLS profiles for IoT devices 11 draft-reddy-opsawg-mud-tls-05 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 March 3, 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 . . . . . . . . . . . . . . . . . . . 17 65 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 70 11.2. Informative References . . . . . . . . . . . . . . . . . 19 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 signature algorithms the client is willing to accept for 383 CertificateVerify message (Section 4.2.3 of [RFC8446]). For 384 example, a TLS client implementation can support different sets of 385 algorithms for certificates and in TLS to signal the capabilities 386 in "signature_algorithms_cert" and "signature_algorithms" 387 extensions. 389 o List of supported application protocols (e.g., h3, h2, http/1.1 390 etc.) 392 o List of certificate compression algorithms (defined in 393 [I-D.ietf-tls-certificate-compression]) 395 o List of the distinguished names [X501] of acceptable certificate 396 authorities, represented in DER-encoded format [X690] (defined in 397 Section 4.2.4 of [RFC8446]) 399 o List of client key exchange algorithms and the client public key 400 lengths in versions prior to (D)TLS 1.3 402 The (D)TLS profile parameters include the GREASE values for extension 403 types, named groups, signature algorithms, (D)TLS versions, pre- 404 shared key exchange modes and cipher suites, but normalized to the 405 value 0x0a to preserve ordering information. Note that the GREASE 406 values are random but their positions are deterministic (Section 5 of 407 [RFC8701]) and peers will ignore these values and interoperate. 409 If the (D)TLS profile parameters are not observed in a (D)TLS session 410 from the IoT device, the default behaviour is to block the (D)TLS 411 session. 413 Note: The TLS and DTLS IANA registries are available from 414 . 416 5.1. Tree Structure 418 This document augments the "ietf-mud" MUD YANG module defined in 419 [RFC8520] for signaling the IoT device (D)TLS profile. This document 420 defines the YANG module "reddy-opsawg-mud-tls-profile", which has the 421 following tree structure: 423 module: reddy-opsawg-mud-tls-profile 424 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: 425 +--rw client-profile 426 +--rw tls-profiles* [profile-name] 427 +--rw profile-name string 428 +--rw protocol-version? uint16 429 +--rw supported_versions* uint16 430 +--rw grease_extension? boolean 431 +--rw encryption-algorithms* encryption-algorithm 432 +--rw compression-methods* compression-method 433 +--rw extension-types* extension-type 434 +--rw acceptlist-ta-certs* ct:trust-anchor-cert-cms 435 +--rw SPKI-pin-sets* SPKI-pin-set 436 +--rw SPKI-hash-algorithm? iha:hash-algorithm-type 437 +--rw psk-key-exchange-modes* psk-key-exchange-mode 438 +--rw supported-groups* supported-group 439 +--rw signature-algorithms-cert* signature-algorithm 440 +--rw signature-algorithms* signature-algorithm 441 +--rw application-protocols* application-protocol 442 +--rw cert-compression-algorithms* cert-compression-algorithm 443 +--rw certificate_authorities* certificate_authorities 444 +--rw client-public-keys 445 +--rw key-exchange-algorithms* key-exchange-algorithm 446 +--rw client-public-key-lengths* client-public-key-length 448 5.2. YANG Module 450 module reddy-opsawg-mud-tls-profile { 451 yang-version 1.1; 452 namespace "urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile"; 453 prefix mud-tls-profile; 455 import ietf-crypto-types { 456 prefix ct; 457 reference "draft-ietf-netconf-crypto-types-01: 458 Common YANG Data Types for Cryptography"; 459 } 461 import iana-hash-algs { 462 prefix iha; 463 reference 464 "RFC XXXX: Common YANG Data Types for Hash algorithms"; 465 } 467 import ietf-access-control-list { 468 prefix acl; 469 reference 470 "RFC 8519: YANG Data Model for Network Access 471 Control Lists (ACLs)"; 472 } 474 organization 475 "IETF Operations and Management Area Working Group Working Group"; 476 contact 477 "Editor: Konda, Tirumaleswar Reddy 478 "; 480 description 481 "This module contains YANG definition for the IoT device 482 (D)TLS profile. 484 Copyright (c) 2019 IETF Trust and the persons identified as 485 authors of the code. All rights reserved. 487 Redistribution and use in source and binary forms, with or 488 without modification, is permitted pursuant to, and subject 489 to the license terms contained in, the Simplified BSD License 490 set forth in Section 4.c of the IETF Trust's Legal Provisions 491 Relating to IETF Documents 492 (http://trustee.ietf.org/license-info). 494 This version of this YANG module is part of RFC XXXX; see 495 the RFC itself for full legal notices."; 497 revision 2019-06-12 { 498 description 499 "Initial revision"; 500 } 502 typedef compression-method { 503 type uint8; 504 description "Compression method"; 505 } 507 typedef extension-type { 508 type uint16; 509 description "Extension type"; 510 } 512 typedef encryption-algorithm { 513 type uint16; 514 description "Encryption algorithm"; 515 } 517 typedef supported-group { 518 type uint16; 519 description "Named group (DHE or ECDHE)"; 520 } 522 typedef SPKI-pin-set { 523 type binary; 524 description "Subject Public Key Info pin set"; 525 } 527 typedef signature-algorithm { 528 type uint16; 529 description "Signature algorithm"; 530 } 532 typedef key-exchange-algorithm { 533 type uint8; 534 description "key exchange algorithm"; 535 } 537 typedef psk-key-exchange-mode { 538 type uint8; 539 description "pre-shared key exchange mode"; 540 } 542 typedef client-public-key-length { 543 type uint8; 544 description "client public key length"; 545 } 547 typedef application-protocol { 548 type string; 549 description "application protocol"; 550 } 552 typedef cert-compression-algorithm { 553 type uint8; 554 description "certificate compression algorithm"; 555 } 557 typedef certificate_authority { 558 type binary; 559 description "Distinguished Name of Certificate authority"; 560 } 562 grouping client-profile { 563 description 564 "A grouping for (D)TLS profiles."; 565 container client-profile { 566 list tls-profiles { 567 key "profile-name"; 568 description 569 "A list of (D)TLS version profiles supported by the client."; 570 leaf profile-name { 571 type string { 572 length "1..64"; 573 } 574 description 575 "The name of (D)TLS profile; space and special 576 characters are not allowed."; 577 } 578 leaf protocol-version { 579 type uint16; 580 description "(D)TLS version in ClientHello.legacy_version"; 581 } 582 leaf-list supported_versions { 583 type uint16; 584 description 585 "TLS versions supported by the client indicated 586 in the supported_versions extension in (D)TLS 1.3."; 587 } 588 leaf grease_extension { 589 type boolean; 590 description 591 "If set to 'true', Grease extension values are offered by 592 the client."; 593 } 594 leaf-list encryption-algorithms { 595 type encryption-algorithm; 596 description "Encryption algorithms"; 597 } 598 leaf-list compression-methods { 599 type compression-method; 600 description "Compression methods"; 601 } 602 leaf-list extension-types { 603 type extension-type; 604 description "Extension Types"; 605 } 606 leaf-list acceptlist-ta-certs { 607 type ct:trust-anchor-cert-cms; 608 description 609 "A list of trust anchor certificates used by the client."; 610 } 611 leaf-list SPKI-pin-sets { 612 type SPKI-pin-set; 613 description 614 "A list of SPKI pin sets pre-configured on the client 615 to validate self-signed server certificate or 616 raw public key."; 617 } 618 leaf SPKI-hash-algorithm { 619 type iha:hash-algorithm-type; 620 description 621 "cryptographic hash algorithm used to generate the 622 SPKI pinset."; 623 } 624 leaf-list psk-key-exchange-modes { 625 type psk-key-exchange-mode; 626 description 627 "pre-shared key exchange modes"; 628 } 629 leaf-list supported-groups { 630 type supported-group; 631 description 632 "A list of named groups supported by the client."; 633 } 634 leaf-list signature-algorithms-cert { 635 type signature-algorithm; 636 description 637 "A list signature algorithms the client can validate 638 in X.509 certificates."; 639 } 640 leaf-list signature-algorithms { 641 type signature-algorithm; 642 description 643 "A list signature algorithms the client can validate 644 in the CertificateVerify message."; 645 } 646 leaf-list application-protocols { 647 type application-protocol; 648 description 649 "A list application protocols supported by the client"; 650 } 651 leaf-list cert-compression-algorithms { 652 type cert-compression-algorithm; 653 description 654 "A list certificate compression algorithms 655 supported by the client"; 656 } 657 leaf-list certificate_authorities { 658 type certificate_authority; 659 description 660 "A list of the distinguished names of certificate authorities 661 acceptable to the client"; 663 } 664 container client-public-keys { 665 leaf-list key-exchange-algorithms { 666 type key-exchange-algorithm; 667 description 668 "Key exchange algorithms supported by the client"; 669 } 670 leaf-list client-public-key-lengths { 671 type client-public-key-length; 672 description 673 "client public key lengths"; 674 } 675 } 676 } 677 } 678 } 679 augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" { 680 description 681 "MUD (D)TLS specific matches."; 682 uses client-profile; 683 } 684 } 686 6. MUD File Example 688 This example below contains (D)TLS profile parameters for a IoT 689 device used to reach servers listening on port 443 using TCP 690 transport. JSON encoding of YANG modelled data [RFC7951] is used to 691 illustrate the example. 693 { 694 "ietf-mud:mud": { 695 "mud-version": 1, 696 "mud-url": "https://example.com/IoTDevice", 697 "last-update": "2019-18-06T03:56:40.105+10:00", 698 "cache-validity": 100, 699 "is-supported": true, 700 "systeminfo": "IoT device name", 701 "from-device-policy": { 702 "access-lists": { 703 "access-list": [ 704 { 705 "name": "mud-7500-profile" 706 } 707 ] 708 } 709 }, 710 "ietf-access-control-list:acls": { 711 "acl": [ 712 { 713 "name": "mud-7500-profile", 714 "type": "ipv6-acl-type", 715 "aces": { 716 "ace": [ 717 { 718 "name": "cl0-frdev", 719 "matches": { 720 "ipv6": { 721 "protocol": 6 722 }, 723 "tcp": { 724 "ietf-mud:direction-initiated": "from-device", 725 "destination-port": { 726 "operator": "eq", 727 "port": 443 728 } 729 }, 730 "reddy-opsawg-mud-tls-profile:client-profile" : { 731 "tls-profiles" : [ 732 { 733 "protocol-version" : 771, 734 "supported_versions_ext" : "FALSE", 735 "encryption-algorithms" : 736 [31354, 4865, 4866, 4867], 737 "extension-types" : [10], 738 "supported-groups" : [29] 739 } 740 ] 741 }, 742 "actions": { 743 "forwarding": "accept" 744 } 745 } 746 } 747 ] 748 } 749 } 750 ] 751 } 752 } 753 } 755 7. Security Considerations 757 Security considerations in [RFC8520] need to be taken into 758 consideration. Although it is challenging for a malware to mimic the 759 TLS behavior of various IoT device types and IoT device models from 760 several manufacturers, malicious agents have a very low probabilty of 761 using the same (D)TLS profile parameters as legitimate agents on the 762 IoT device to evade detection. Network security services should also 763 rely on contextual network data to detect false negatives. In order 764 to detect such malicious flows, anomaly detection (deep learning 765 techniques on network data) can be used to detect malicious agents 766 using the same (D)TLS profile parameters as legitimate agent on the 767 IoT device. In anomaly detection, the main idea is to maintain 768 rigorous learning of "normal" behavior and where an "anomaly" (or an 769 attack) is identified and categorized based on the knowledge about 770 the normal behavior and a deviation from this normal behavior. 772 8. Privacy Considerations 774 The middle-box acting as a (D)TLS proxy must immediately delete the 775 decrypted data upon completing any necessary inspection functions. 776 TLS proxy potentially has access to a user's PII (Personally 777 identifiable information) and PHI (Protected Health Information). 778 The TLS proxy must not store, process or modify PII data. For 779 example, IT administrator can configure firewall to bypass payload 780 inspection for a connection destined to a specific service due to 781 privacy compliance requirements. 783 9. IANA Considerations 785 This document requests IANA to register the following URIs in the 786 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 788 URI: urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile 789 Registrant Contact: The IESG. 790 XML: N/A; the requested URI is an XML namespace. 792 10. Acknowledgments 794 Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson, 795 Piyush Joshi and Harsha Joshi for the discussion and comments. 797 11. References 798 11.1. Normative References 800 [I-D.ietf-netconf-crypto-types] 801 Watsen, K., "YANG Data Types and Groupings for 802 Cryptography", draft-ietf-netconf-crypto-types-18 (work in 803 progress), August 2020. 805 [I-D.ietf-tls-certificate-compression] 806 Ghedini, A. and V. Vasiliev, "TLS Certificate 807 Compression", draft-ietf-tls-certificate-compression-10 808 (work in progress), January 2020. 810 [I-D.ietf-tls-dtls13] 811 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 812 Datagram Transport Layer Security (DTLS) Protocol Version 813 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 814 2020. 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, 818 DOI 10.17487/RFC2119, March 1997, 819 . 821 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 822 DOI 10.17487/RFC3688, January 2004, 823 . 825 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 826 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 827 January 2012, . 829 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 830 RFC 6991, DOI 10.17487/RFC6991, July 2013, 831 . 833 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 834 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 835 May 2017, . 837 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 838 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 839 . 841 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 842 "YANG Data Model for Network Access Control Lists (ACLs)", 843 RFC 8519, DOI 10.17487/RFC8519, March 2019, 844 . 846 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 847 Sustain Extensibility (GREASE) to TLS Extensibility", 848 RFC 8701, DOI 10.17487/RFC8701, January 2020, 849 . 851 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 852 Specification of Basic Encoding Rules (BER), Canonical 853 Encoding Rules (CER) and Distinguished Encoding Rules 854 (DER)", ISO/IEC 8825-1:2002, 2002. 856 11.2. Informative References 858 [cryto-vulnerability] 859 Perez, B., "Exploiting the Windows CryptoAPI 860 Vulnerability", January 2020, 861 . 864 [I-D.ietf-dnsop-svcb-https] 865 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 866 and parameter specification via the DNS (DNS SVCB and 867 HTTPS RRs)", draft-ietf-dnsop-svcb-https-01 (work in 868 progress), July 2020. 870 [I-D.ietf-tls-sni-encryption] 871 Huitema, C. and E. Rescorla, "Issues and Requirements for 872 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-09 873 (work in progress), October 2019. 875 [I-D.reddy-add-enterprise] 876 Reddy.K, T. and D. Wing, "DNS-over-HTTPS and DNS-over-TLS 877 Server Deployment Considerations for Enterprise Networks", 878 draft-reddy-add-enterprise-00 (work in progress), June 879 2020. 881 [malware] Anderson, B., Paul, S., and D. McGrew, "Deciphering 882 Malware's use of TLS (without Decryption)", July 2016, 883 . 885 [malware-doh] 886 Cimpanu, C., "First-ever malware strain spotted abusing 887 new DoH (DNS over HTTPS) protocol", July 2019, 888 . 891 [malware-tls] 892 Anderson, B. and D. McGrew, "TLS Beyond the Browser: 893 Combining End Host and Network Data to Understand 894 Application Behavior", October 2019, 895 . 897 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 898 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 899 2015, . 901 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 902 and P. Hoffman, "Specification for DNS over Transport 903 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 904 2016, . 906 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 907 RFC 7951, DOI 10.17487/RFC7951, August 2016, 908 . 910 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 911 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 912 . 914 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 915 Description Specification", RFC 8520, 916 DOI 10.17487/RFC8520, March 2019, 917 . 919 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 920 Things (IoT) Security: State of the Art and Challenges", 921 RFC 8576, DOI 10.17487/RFC8576, April 2019, 922 . 924 [X501] "Information Technology - Open Systems Interconnection - 925 The Directory: Models", ITU-T X.501, 1993. 927 Authors' Addresses 929 Tirumaleswar Reddy 930 McAfee, Inc. 931 Embassy Golf Link Business Park 932 Bangalore, Karnataka 560071 933 India 935 Email: kondtir@gmail.com 936 Dan Wing 937 Citrix Systems, Inc. 938 4988 Great America Pkwy 939 Santa Clara, CA 95054 940 USA 942 Email: danwing@gmail.com 944 Blake Anderson 945 Cisco Systems, Inc. 946 170 West Tasman Dr 947 San Jose, CA 95134 948 USA 950 Email: blake.anderson@cisco.com