idnits 2.17.1 draft-reddy-opsawg-mud-tls-03.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 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 (January 29, 2020) is 1549 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 661 -- Looks like a reference, but probably isn't: '4865' on line 661 -- Looks like a reference, but probably isn't: '4866' on line 661 -- Looks like a reference, but probably isn't: '4867' on line 661 -- Looks like a reference, but probably isn't: '10' on line 662 -- Looks like a reference, but probably isn't: '29' on line 663 == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-13 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-34 ** Downref: Normative reference to an Informational draft: draft-ietf-tls-grease (ref. 'I-D.ietf-tls-grease') ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-08) exists of draft-reddy-dprive-bootstrap-dns-server-06 Summary: 2 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: August 1, 2020 Citrix 6 B. Anderson 7 Cisco 8 January 29, 2020 10 MUD (D)TLS profiles for IoT devices 11 draft-reddy-opsawg-mud-tls-03 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 August 1, 2020. 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 . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . 9 63 6. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 13 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 65 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 70 11.2. Informative References . . . . . . . . . . . . . . . . . 17 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 3. Overview of MUD (D)TLS profiles for IoT devices 189 In Enterprise networks, protection and detection are typically done 190 both on end hosts and in the network. Host agents have deep 191 visibility on the devices where they are installed, whereas the 192 network has broader visibility. Installing host agents may not be a 193 viable option on IoT devices, and network-based security is an 194 efficient means to protect such IoT devices. (D)TLS profile 195 parameters of IoT device can be used by middle-boxes to detect and 196 block malware communication, while at the same time preserving the 197 privacy of legitimate uses of encryption. Middle-boxes need not 198 proxy (D)TLS but can passively observe the parameters of (D)TLS 199 handshakes from IoT devices and gain good visibility into TLS 1.0 to 200 1.2 parameters and partial visibility into TLS 1.3 parameters. 201 Malicious agents can try to use the (D)TLS profile parameters of 202 legitimate agents to evade detection, but it becomes a challenge to 203 mimic the behavior of various IoT device types and IoT device models 204 from several manufacturers. In other words, malware developers will 205 have to develop malicious agents per IoT device type, manufacturer 206 and model, infect the device with the tailored malware agent and will 207 have keep up with updates to the device's (D)TLS profile parameters 208 over time. Further, the malware's command and control server 209 certificates need to be signed by the same certifying authorities 210 trusted by the IoT devices. Typically, IoT devices have an 211 infrastructure that supports a rapid deployment of updates, and 212 malware agents will have a near-impossible task of similarly 213 deploying updates and continuing to mimic the TLS behavior of the IoT 214 device it has infected. 216 The compromised IoT devices are typically used for launching DDoS 217 attacks (Section 3 of [RFC8576]). Some of the DDoS attacks like 218 Slowloris and Transport Layer Security (TLS) re-negotiation can be 219 detected by observing the (D)TLS profile parameters. For example, 220 the victim's server certificate need not be signed by the same 221 certifying authorities trusted by the IoT device. 223 4. (D)TLS 1.3 handshake 225 In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since 226 all (D)TLS handshake messages excluding the ClientHello message are 227 encrypted. (D)TLS 1.3 has introduced new extensions in the handshake 228 record layers called Encrypted Extensions. Using these extensions 229 handshake messages will be encrypted and network devices (such as a 230 firewall) are incapable deciphering the handshake, thus cannot view 231 the server certificate. However, the ClientHello and ServerHello 232 still have some fields visible, such as the list of supported 233 versions, named groups, cipher suites, signature algorithms and 234 extensions in ClientHello and, chosen cipher in the ServerHello. For 235 instance, if the malware uses evasion techniques like ClientHello 236 randomization, the observable list of cipher suites and extensions 237 offered by the malware agent in the ClientHello message will not 238 match the list of cipher suites and extensions offered by the 239 legitimate client in the ClientHello message, and the middle-box can 240 block malicious flows without acting as a (D)TLS 1.3 proxy. 242 4.1. Full (D)TLS 1.3 handshake inspection 244 To obtain more visibility into negotiated TLS 1.3 parameters, a 245 middle-box can act as a (D)TLS 1.3 proxy. A middle-box can act as a 246 (D)TLS proxy for the IoT devices owned and managed by the IT team in 247 the Enterprise network and the (D)TLS proxy must meet the security 248 and privacy requirements of the organization. In other words, the 249 scope of middle-box acting as a (D)TLS proxy is restricted to 250 Enterprise network owning and managing the IoT devices. The middle- 251 box MUST follow the behaviour explained in Section 9.3 of [RFC8446] 252 to act as a compliant (D)TLS 1.3 proxy. 254 To function as a (D)TLS proxy the middle-box creates a signed 255 certificate using itself as a certificate authority. That 256 certificate authority has to be trusted by the (D)TLS client. The 257 IoT device needs to be configured with the middle-box's CA 258 certificate as Explicit Trust Anchor database entry to validate the 259 server certificate. The mechanism to configure the IoT device with 260 the middle-box's CA certificate is out of scope. The middle-box uses 261 the "supported_versions" TLS extension (defined in TLS 1.3 to 262 negotiate the supported TLS versions between client and server) to 263 determine the TLS version. During the (D)TLS handshake, If (D)TLS 264 version 1.3 is used, the middle-box ((D)TLS proxy) modifies the 265 certificate provided by the server and signs it with the private key 266 from the local CA certificate. The middle-box has visibility into 267 further exchanges between the IoT device and server which enables it 268 to inspect the (D)TLS 1.3 handshake, enforce the MUD (D)TLS profile 269 and can inspect subsequent network traffic. The IoT device uses the 270 Explicit Trust Anchor database to validate the server certificate. 272 4.2. Encrypted SNI 274 To increase privacy, encrypted SNI (ESNI, 275 [I-D.ietf-tls-sni-encryption]) prevents passive observation of the 276 TLS Server Name Indication extension. To effectively provide that 277 privacy protection, SNI encryption needs to be used in conjunction 278 with DNS encryption (e.g., DNS-over-(D)TLS or DNS-over-HTTPS). A 279 middle-box (e.g., firewall) passively inspecting an encrypted SNI 280 (D)TLS handshake cannot observe the encrypted SNI nor observe the 281 encrypted DNS traffic. If an IoT device is pre-configured to use 282 public DNS-over-(D)TLS or DNS-over-HTTPS servers, that middle-box 283 needs to act as a DNS-over-TLS or DNS-over-HTTPS proxy and replace 284 the esni_keys in the ESNI record with the middle box's esni_keys. 285 Instead of an unappealing DNS-over-TLS or DNS-over-HTTPS proxy, the 286 IoT device can be bootstrapped to discover and authenticate DNS- 287 over-(D)TLS and DNS-over-HTTPS servers provided by a local network 288 using [I-D.reddy-dprive-bootstrap-dns-server] and 289 [I-D.sah-resinfo-doh]. The local DNS-over-(D)TLS and DNS-over-HTTPS 290 server replaces the sni_keys in the ESNI record with the middle box's 291 esni_keys. 293 Note that if an IoT device is pre-configured to use public DNS- 294 over-(D)TLS or DNS-over-HTTPS servers, the MUD policy enforcement 295 point is moved to that public server, which cannot enforce the MUD 296 policy based on domain names (Section 8 of [RFC8520]). Thus the use 297 of a public DNS-over-(D)TLS or DNS-over-HTTPS server is incompatible 298 with MUD in general. A local DNS server is necessary to allow MUD 299 policy enforcement on the local network. 301 5. (D)TLS profile YANG module 303 This document specifies a YANG module for representing (D)TLS 304 profile. The (D)TLS profile YANG module provides a method for 305 firewall to observe the (D)TLS profile parameters in the (D)TLS 306 handshake to permit intended use and to block malicious behavior. 307 This module uses the common YANG types defined in [RFC6991] , rules 308 defined in [RFC8519] and cryptographic types defined in 309 [I-D.ietf-netconf-crypto-types]. 311 The (D)TLS profiles and the parameters in each (D)TLS profile include 312 the following: 314 o Profile name 316 o (D)TLS version in ClientHello.legacy_version 318 o (D)TLS versions supported by the IoT device. As a reminder, 319 "supported_versions" extension defined in (D)TLS 1.3 is used by 320 the client to indicate which versions of (D)TLS it supports and a 321 client is considered to be attempting to negotiate (D)TLS 1.3 if 322 the ClientHello contains a "supported_versions" extension with 323 0x0304 contained in its body. 325 o If GREASE [I-D.ietf-tls-grease] (Generate Random Extensions And 326 Sustain Extensibility) values are offered by the client or not. 328 o List of supported symmetric encryption algorithms 330 o List of supported compression methods 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 middle-box continues with the connection as normal. Otherwise, 337 the middle-box will react as if the server certificate validation 338 has 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). 345 o List of SPKI pin set pre-configured on the client to validate 346 self-signed server certificates or raw public keys. A SPKI pin 347 set is a cryptographic digest to "pin" public key information in a 348 manner similar to HTTP Public Key Pinning (HPKP) [RFC7469]. If 349 SPKI pin set is present in the (D)TLS profile of a IoT device and 350 the server certificate does not pass the PKIX certification path 351 validation, the middle-box computes the SPKI Fingerprint for the 352 public key found in the server's certificate (or in the raw public 353 key, if the server provides that instead). If a computed 354 fingerprint exactly matches one of the SPKI pin sets in the (D)TLS 355 profile, the middle-box continues with the connection as normal. 356 Otherwise, the middle-box will act on the SPKI validation failure 357 and takes appropriate action. 359 o Cryptographic hash algorithm used to generate the SPKI pinsets 361 o List of pre-shared key exchange modes 363 o List of named groups (DHE or ECDHE) supported by the client 365 o List signature algorithms the client can validate in X.509 server 366 certificates 368 o List of client key exchange algorithms and the client public key 369 lengths in versions prior to (D)TLS 1.3 371 The (D)TLS profile parameters MUST NOT include the GREASE values for 372 extension types, named groups, signature algorithms, (D)TLS versions, 373 pre-shared key exchange modes and cipher suites. Note that the 374 GREASE values are random and peers will ignore these values and 375 interoperate. 377 If the (D)TLS profile parameters are not observed in a (D)TLS session 378 from the IoT device, the default behaviour is to block the (D)TLS 379 session. 381 Note: The TLS and DTLS IANA registries are available from 382 . 384 5.1. Tree Structure 386 This document augments the "ietf-mud" MUD YANG module defined in 387 [RFC8520] for signaling the IoT device (D)TLS profile. This document 388 defines the YANG module "reddy-opsawg-mud-tls-profile", which has the 389 following tree structure: 391 module: reddy-opsawg-mud-tls-profile 392 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: 393 +--rw client-profile 394 +--rw tls-profiles* [profile-name] 395 +--rw profile-name string 396 +--rw protocol-version? uint16 397 +--rw supported_versions* uint16 398 +--rw grease_extension? boolean 399 +--rw encryption-algorithms* encryption-algorithm 400 +--rw compression-methods* compression-method 401 +--rw extension-types* extension-type 402 +--rw acceptlist-ta-certs* ct:trust-anchor-cert-cms 403 +--rw SPKI-pin-sets* SPKI-pin-set 404 +--rw SPKI-hash-algorithm? iha:hash-algorithm-type 405 +--rw psk-key-exchange-modes* psk-key-exchange-mode 406 +--rw supported-groups* supported-group 407 +--rw signature-algorithms* signature-algorithm 408 +--rw client-public-keys 409 +--rw key-exchange-algorithms* key-exchange-algorithm 410 +--rw client-public-key-lengths* client-public-key-length 412 5.2. YANG Module 414 module reddy-opsawg-mud-tls-profile { 415 yang-version 1.1; 416 namespace "urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile"; 417 prefix mud-tls-profile; 419 import ietf-crypto-types { 420 prefix ct; 421 reference "draft-ietf-netconf-crypto-types-01: 422 Common YANG Data Types for Cryptography"; 423 } 425 import iana-hash-algs { 426 prefix iha; 427 reference 428 "RFC XXXX: Common YANG Data Types for Hash algorithms"; 429 } 430 import ietf-access-control-list { 431 prefix acl; 432 reference 433 "RFC 8519: YANG Data Model for Network Access 434 Control Lists (ACLs)"; 435 } 437 organization 438 "IETF Operations and Management Area Working Group Working Group"; 439 contact 440 "Editor: Konda, Tirumaleswar Reddy 441 "; 443 description 444 "This module contains YANG definition for the IoT device 445 (D)TLS profile. 447 Copyright (c) 2019 IETF Trust and the persons identified as 448 authors of the code. All rights reserved. 450 Redistribution and use in source and binary forms, with or 451 without modification, is permitted pursuant to, and subject 452 to the license terms contained in, the Simplified BSD License 453 set forth in Section 4.c of the IETF Trust's Legal Provisions 454 Relating to IETF Documents 455 (http://trustee.ietf.org/license-info). 457 This version of this YANG module is part of RFC XXXX; see 458 the RFC itself for full legal notices."; 460 revision 2019-06-12 { 461 description 462 "Initial revision"; 463 } 465 typedef compression-method { 466 type uint8; 467 description "Compression method"; 468 } 470 typedef extension-type { 471 type uint16; 472 description "Extension type"; 473 } 475 typedef encryption-algorithm { 476 type uint16; 477 description "Encryption algorithm"; 479 } 481 typedef supported-group { 482 type uint16; 483 description "Named group (DHE or ECDHE)"; 484 } 486 typedef SPKI-pin-set { 487 type binary; 488 description "Subject Public Key Info pin set"; 489 } 491 typedef signature-algorithm { 492 type uint16; 493 description "Signature algorithm"; 494 } 496 typedef key-exchange-algorithm { 497 type uint8; 498 description "key exchange algorithm"; 499 } 501 typedef psk-key-exchange-mode { 502 type uint8; 503 description "pre-shared key exchange mode"; 504 } 506 typedef client-public-key-length { 507 type uint8; 508 description "client public key length"; 509 } 511 grouping client-profile { 512 description 513 "A grouping for (D)TLS profiles."; 514 container client-profile { 515 list tls-profiles { 516 key "profile-name"; 517 description 518 "A list of (D)TLS version profiles supported by the client."; 519 leaf profile-name { 520 type string { 521 length "1..64"; 522 } 523 description 524 "The name of (D)TLS profile; space and special 525 characters are not allowed."; 526 } 527 leaf protocol-version { 528 type uint16; 529 description "(D)TLS version in ClientHello.legacy_version"; 530 } 531 leaf-list supported_versions { 532 type uint16; 533 description 534 "TLS versions supported by the client indicated 535 in the supported_versions extension in (D)TLS 1.3."; 536 } 537 leaf grease_extension { 538 type boolean; 539 description 540 "If set to 'true', Grease extension values are offered by 541 the client."; 542 } 543 leaf-list encryption-algorithms { 544 type encryption-algorithm; 545 description "Encryption algorithms"; 546 } 547 leaf-list compression-methods { 548 type compression-method; 549 description "Compression methods"; 550 } 551 leaf-list extension-types { 552 type extension-type; 553 description "Extension Types"; 554 } 555 leaf-list acceptlist-ta-certs { 556 type ct:trust-anchor-cert-cms; 557 description 558 "A list of trust anchor certificates used by the client."; 559 } 560 leaf-list SPKI-pin-sets { 561 type SPKI-pin-set; 562 description 563 "A list of SPKI pin sets pre-configured on the client 564 to validate self-signed server certificate or 565 raw public key."; 566 } 567 leaf SPKI-hash-algorithm { 568 type iha:hash-algorithm-type; 569 description 570 "cryptographic hash algorithm used to generate the 571 SPKI pinset."; 572 } 573 leaf-list psk-key-exchange-modes { 574 type psk-key-exchange-mode; 575 description 576 "pre-shared key exchange modes"; 577 } 578 leaf-list supported-groups { 579 type supported-group; 580 description 581 "A list of named groups supported by the client."; 582 } 583 leaf-list signature-algorithms { 584 type signature-algorithm; 585 description 586 "A list signature algorithms the client can validate 587 in X.509 certificates."; 588 } 589 container client-public-keys { 590 leaf-list key-exchange-algorithms { 591 type key-exchange-algorithm; 592 description 593 "Key exchange algorithms supported by the client"; 594 } 595 leaf-list client-public-key-lengths { 596 type client-public-key-length; 597 description 598 "client public key lengths"; 599 } 600 } 601 } 602 } 603 } 604 augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" { 605 description 606 "MUD (D)TLS specific matches."; 607 uses client-profile; 608 } 609 } 611 6. MUD File Example 613 This example below contains (D)TLS profile parameters for a IoT 614 device used to reach servers listening on port 443 using TCP 615 transport. JSON encoding of YANG modelled data [RFC7951] is used to 616 illustrate the example. 618 { 619 "ietf-mud:mud": { 620 "mud-version": 1, 621 "mud-url": "https://example.com/IoTDevice", 622 "last-update": "2019-18-06T03:56:40.105+10:00", 623 "cache-validity": 100, 624 "is-supported": true, 625 "systeminfo": "IoT device name", 626 "from-device-policy": { 627 "access-lists": { 628 "access-list": [ 629 { 630 "name": "mud-7500-profile" 631 } 632 ] 633 } 634 }, 635 "ietf-access-control-list:acls": { 636 "acl": [ 637 { 638 "name": "mud-7500-profile", 639 "type": "ipv6-acl-type", 640 "aces": { 641 "ace": [ 642 { 643 "name": "cl0-frdev", 644 "matches": { 645 "ipv6": { 646 "protocol": 6 647 }, 648 "tcp": { 649 "ietf-mud:direction-initiated": "from-device", 650 "destination-port": { 651 "operator": "eq", 652 "port": 443 653 } 654 }, 655 "reddy-opsawg-mud-tls-profile:client-profile" : { 656 "tls-profiles" : [ 657 { 658 "protocol-version" : 771, 659 "supported_versions_ext" : "FALSE", 660 "encryption-algorithms" : 661 [31354, 4865, 4866, 4867], 662 "extension-types" : [10], 663 "supported-groups" : [29] 664 } 665 ] 666 }, 667 "actions": { 668 "forwarding": "accept" 669 } 670 } 672 } 673 ] 674 } 675 } 676 ] 677 } 678 } 679 } 681 7. Security Considerations 683 Security considerations in [RFC8520] need to be taken into 684 consideration. Although it is challenging for a malware to mimic the 685 TLS behavior of various IoT device types and IoT device models from 686 several manufacturers, malicious agents have a very low probabilty of 687 using the same (D)TLS profile parameters as legitimate agents on the 688 IoT device to evade detection. Network security services should also 689 rely on contextual network data to detect false negatives. In order 690 to detect such malicious flows, anomaly detection (deep learning 691 techniques on network data) can be used to detect malicious agents 692 using the same (D)TLS profile parameters as legitimate agent on the 693 IoT device. In anomaly detection, the main idea is to maintain 694 rigorous learning of "normal" behavior and where an "anomaly" (or an 695 attack) is identified and categorized based on the knowledge about 696 the normal behavior and a deviation from this normal behavior. 698 8. Privacy Considerations 700 The middle-box acting as a (D)TLS proxy must immediately delete the 701 decrypted data upon completing any necessary inspection functions. 702 TLS proxy potentially has access to a user's PII (Personally 703 identifiable information) and PHI (Protected Health Information). 704 The TLS proxy must not store, process or modify PII data. For 705 example, IT administrator can configure firewall to bypass payload 706 inspection for a connection destined to a specific service due to 707 privacy compliance requirements. 709 9. IANA Considerations 711 This document requests IANA to register the following URIs in the 712 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 714 URI: urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile 715 Registrant Contact: The IESG. 716 XML: N/A; the requested URI is an XML namespace. 718 10. Acknowledgments 720 Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson and 721 Harsha Joshi for the discussion and comments. 723 11. References 725 11.1. Normative References 727 [I-D.ietf-netconf-crypto-types] 728 Watsen, K. and H. Wang, "Common YANG Data Types for 729 Cryptography", draft-ietf-netconf-crypto-types-13 (work in 730 progress), November 2019. 732 [I-D.ietf-tls-dtls13] 733 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 734 Datagram Transport Layer Security (DTLS) Protocol Version 735 1.3", draft-ietf-tls-dtls13-34 (work in progress), 736 November 2019. 738 [I-D.ietf-tls-grease] 739 Benjamin, D., "Applying GREASE to TLS Extensibility", 740 draft-ietf-tls-grease-04 (work in progress), August 2019. 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, 744 DOI 10.17487/RFC2119, March 1997, 745 . 747 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 748 DOI 10.17487/RFC3688, January 2004, 749 . 751 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 752 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 753 January 2012, . 755 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 756 RFC 6991, DOI 10.17487/RFC6991, July 2013, 757 . 759 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 760 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 761 May 2017, . 763 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 764 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 765 . 767 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 768 "YANG Data Model for Network Access Control Lists (ACLs)", 769 RFC 8519, DOI 10.17487/RFC8519, March 2019, 770 . 772 11.2. Informative References 774 [cryto-vulnerability] 775 Perez, B., "Exploiting the Windows CryptoAPI 776 Vulnerability", January 2020, 777 . 780 [I-D.ietf-tls-sni-encryption] 781 Huitema, C. and E. Rescorla, "Issues and Requirements for 782 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-09 783 (work in progress), October 2019. 785 [I-D.reddy-dprive-bootstrap-dns-server] 786 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 787 "A Bootstrapping Procedure to Discover and Authenticate 788 DNS-over-(D)TLS and DNS-over-HTTPS Servers", draft-reddy- 789 dprive-bootstrap-dns-server-06 (work in progress), January 790 2020. 792 [I-D.sah-resinfo-doh] 793 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 794 Information: "doh"", draft-sah-resinfo-doh-00 (work in 795 progress), May 2019. 797 [malware] Anderson, B., Paul, S., and D. McGrew, "Deciphering 798 Malware's use of TLS (without Decryption)", July 2016, 799 . 801 [malware-doh] 802 Cimpanu, C., "First-ever malware strain spotted abusing 803 new DoH (DNS over HTTPS) protocol", July 2019, 804 . 807 [malware-tls] 808 Anderson, B. and D. McGrew, "TLS Beyond the Browser: 809 Combining End Host and Network Data to Understand 810 Application Behavior", October 2019, 811 . 813 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 814 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 815 2015, . 817 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 818 RFC 7951, DOI 10.17487/RFC7951, August 2016, 819 . 821 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 822 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 823 . 825 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 826 Description Specification", RFC 8520, 827 DOI 10.17487/RFC8520, March 2019, 828 . 830 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 831 Things (IoT) Security: State of the Art and Challenges", 832 RFC 8576, DOI 10.17487/RFC8576, April 2019, 833 . 835 Authors' Addresses 837 Tirumaleswar Reddy 838 McAfee, Inc. 839 Embassy Golf Link Business Park 840 Bangalore, Karnataka 560071 841 India 843 Email: kondtir@gmail.com 845 Dan Wing 846 Citrix Systems, Inc. 847 4988 Great America Pkwy 848 Santa Clara, CA 95054 849 USA 851 Email: danwing@gmail.com 852 Blake Anderson 853 Cisco Systems, Inc. 854 170 West Tasman Dr 855 San Jose, CA 95134 856 USA 858 Email: blake.anderson@cisco.com