idnits 2.17.1 draft-ietf-opsawg-mud-tls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 24 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 == Line 407 has weird spacing: '... cipher cip...' -- The document date (October 5, 2020) is 1298 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: '2' on line 803 -- Looks like a reference, but probably isn't: '10' on line 814 -- Looks like a reference, but probably isn't: '11' on line 814 -- Looks like a reference, but probably isn't: '13' on line 814 -- Looks like a reference, but probably isn't: '16' on line 814 -- Looks like a reference, but probably isn't: '24' on line 814 -- Looks like a reference, but probably isn't: '29' on line 815 == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-18 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 8701 -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-07 == Outdated reference: A later version (-09) exists of draft-ietf-uta-tls13-iot-profile-00 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG WG T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track D. Wing 5 Expires: April 8, 2021 Citrix 6 B. Anderson 7 Cisco 8 October 5, 2020 10 Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices 11 draft-ietf-opsawg-mud-tls-01 13 Abstract 15 This memo extends the Manufacturer Usage Description (MUD) 16 specification to incorporate (D)TLS profile parameters. This allows 17 a network security service to identify unexpected (D)TLS usage, which 18 can indicate the presence of unauthorized software or malware on an 19 endpoint. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 8, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Overview of MUD (D)TLS profiles for IoT devices . . . . . . . 5 58 4. (D)TLS 1.3 Handshake . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Full (D)TLS 1.3 Handshake Inspection . . . . . . . . . . 6 60 4.2. Encrypted DNS . . . . . . . . . . . . . . . . . . . . . . 6 61 5. (D)TLS Profile YANG Module . . . . . . . . . . . . . . . . . 7 62 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 9 63 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10 64 6. Processing of the MUD (D)TLS Profile . . . . . . . . . . . . 16 65 7. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 17 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 67 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 69 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 72 12.2. Informative References . . . . . . . . . . . . . . . . . 21 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 75 1. Introduction 77 Encryption is necessary to enhance the privacy of end users using IoT 78 devices. TLS [RFC8446] and DTLS [I-D.ietf-tls-dtls13] are the 79 dominant protocols providing encryption for IoT device traffic. 80 Unfortunately, in conjunction with IoT applications' rise of 81 encryption, malware is also using encryption which thwarts network- 82 based analysis such as deep packet inspection (DPI). Other 83 mechanisms are needed to detect malware running on an IoT device. 85 Malware frequently uses its own libraries for its activities, and 86 those libraries are re-used much like any other software engineering 87 project. [malware] indicates that there are observable differences in 88 how malware uses encryption compared with how non-malware uses 89 encryption. There are several interesting findings specific to 90 (D)TLS which were found common to malware: 92 o Older and weaker cryptographic parameters (e.g., 93 TLS_RSA_WITH_RC4_128_SHA). 95 o TLS server name indication (SNI) extension and server certificates 96 are composed of subjects with characteristics of a domain 97 generation algorithm (DGA) (e.g., www.33mhwt2j.net). 99 o Higher use of self-signed certificates compared with typical 100 legitimate software. 102 o Discrepancies in the SNI TLS extension 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 the Client Key Exchange message has been removed from TLS 1.3. 110 o Lower diversity in TLS client advertised extensions compared to 111 legitimate clients. 113 o Using privacy enhancing technologies like Tor, Psiphon, Ultrasurf 114 (see [malware-tls]), and evasion techniques such as ClientHello 115 randomization. 117 o Using DNS-over-HTTPS (DoH) [RFC8484] to avoid detection by malware 118 DNS filtering services [malware-doh]. Specifically, malware may 119 not use the DoH server provided by the local network. 121 If observable (D)TLS profile parameters are used, the following 122 functions are possible which have a positive impact on the local 123 network security: 125 o Permit intended DTLS or TLS use and block malicious DTLS or TLS 126 use. This is superior to the layers 3 and 4 ACLs of Manufacturer 127 Usage Description Specification (MUD) [RFC8520] which are not 128 suitable for broad communication patterns. 130 o Ensure TLS certificates are valid. Several TLS deployments have 131 been vulnerable to active Man-In-The-Middle (MITM) attacks because 132 of the lack of certificate validation or vulnerability in the 133 certificate validation function (see [cryto-vulnerability]). By 134 observing (D)TLS profile parameters, a network element can detect 135 when the TLS SNI mismatches the SubjectAltName and when the 136 server's certificate is invalid. In TLS 1.2, the ClientHello, 137 ServerHello and Certificate messages are all sent in clear-text. 138 This check is not possible with TLS 1.3, which encrypts the 139 Certificate message thereby hiding the server identity from any 140 intermediary. In TLS 1.3, the server certificate validation 141 functions should be executed within an on-path TLS proxy, if such 142 a proxy exists. 144 o Support new communication patterns. An IoT device can learn a new 145 capability, and the new capability can change the way the IoT 146 device communicates with other devices located in the local 147 network and Internet. There would be an inaccurate policy if an 148 IoT device rapidly changes the IP addresses and domain names it 149 communicates with while the MUD ACLs were slower to update. In 150 such a case, observable (D)TLS profile parameters can be used to 151 permit intended use and to block malicious behavior from the IoT 152 device. 154 This document extends MUD [RFC8520] to model observable (D)TLS 155 profile parameters. Using these (D)TLS profile parameters, an active 156 MUD-enforcing network security service (e.g., firewall) can identify 157 MUD non-compliant (D)TLS behavior indicating outdated cryptography or 158 malware. This detection can prevent malware downloads, block access 159 to malicious domains, enforce use of strong ciphers, stop data 160 exfiltration, etc. In addition, organizations may have policies 161 around acceptable ciphers and certificates for the websites the IoT 162 devices connect to. Examples include no use of old and less secure 163 versions of TLS, no use of self-signed certificates, deny-list or 164 accept-list of Certificate Authorities, valid certificate expiration 165 time, etc. These policies can be enforced by observing the (D)TLS 166 profile parameters. Network security services can use the IoT 167 device's (D)TLS profile parameters to identify legitimate flows by 168 observing (D)TLS sessions, and can make inferences to permit 169 legitimate flows and to block malicious or insecure flows. The 170 proposed technique is also suitable in deployments where decryption 171 techniques are not ideal due to privacy concerns, non-cooperating 172 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 security agents have deep 193 visibility on the devices where they are installed, whereas the 194 network has broader visibility. Installing host security agents may 195 not be a viable option on IoT devices, and network-based security is 196 an efficient means to protect such IoT devices. If the IoT device 197 supports a MUD (D)TLS profile, the (D)TLS profile parameters of the 198 IoT device can be used by a middlebox to detect and block malware 199 communication, while at the same time preserving the privacy of 200 legitimate uses of encryption. The middlebox need not proxy (D)TLS 201 but can passively observe the parameters of (D)TLS handshakes from 202 IoT devices and gain visibility into TLS 1.2 parameters and partial 203 visibility into TLS 1.3 parameters. Malicious agents can try to use 204 the (D)TLS profile parameters of legitimate agents to evade 205 detection, but it becomes a challenge to mimic the behavior of 206 various IoT device types and IoT device models from several 207 manufacturers. In other words, malware developers will have to 208 develop malicious agents per IoT device type, manufacturer and model, 209 infect the device with the tailored malware agent and will have keep 210 up with updates to the device's (D)TLS profile parameters over time. 211 Furthermore, the malware's command and control server certificates 212 need to be signed by the same certifying authorities trusted by the 213 IoT devices. Typically, IoT devices have an infrastructure that 214 supports a rapid deployment of updates, and malware agents will have 215 a near-impossible task of similarly deploying updates and continuing 216 to mimic the TLS behavior of the IoT device it has infected. 217 However, if the IoT device has reached end-of-life and the IoT 218 manufcaturer will not issue a firmware or software update to the 219 Thing or will not update the MUD file, the "is-supported" attribute 220 defined in Section 3.6 of [RFC8520] can be used by the MUD manager to 221 identify the IoT manufcaturer no longer supports the device. The 222 end-of-life of a device does not necessarily mean that it is 223 defective; rather, it denotes a need to replace and upgrade the 224 network to next-generation devices for additional functionality. The 225 network security service will have to rely on other techniques 226 discussed in Section 8 to identify malicious connections until the 227 device is replaced. 229 Compromised IoT devices are typically used for launching DDoS attacks 230 (Section 3 of [RFC8576]). For example, DDoS attacks like Slowloris 231 and Transport Layer Security (TLS) re-negotiation can be blocked if 232 the victim's server certificate is not be signed by the same 233 certifying authorities trusted by the IoT device. 235 4. (D)TLS 1.3 Handshake 237 In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since 238 all (D)TLS handshake messages excluding the ClientHello message are 239 encrypted. (D)TLS 1.3 has introduced new extensions in the handshake 240 record layers called Encrypted Extensions. Using these extensions 241 handshake messages will be encrypted and network security services 242 (such as a firewall) are incapable to decipher the handshake, and 243 thus cannot view the server certificate. However, the ClientHello 244 and ServerHello still have some fields visible, such as the list of 245 supported versions, named groups, cipher suites, signature algorithms 246 and extensions in ClientHello, and chosen cipher in the ServerHello. 247 For instance, if the malware uses evasion techniques like ClientHello 248 randomization, the observable list of cipher suites and extensions 249 offered by the malware agent in the ClientHello message will not 250 match the list of cipher suites and extensions offered by the 251 legitimate client in the ClientHello message, and the middlebox can 252 block malicious flows without acting as a (D)TLS 1.3 proxy. 254 4.1. Full (D)TLS 1.3 Handshake Inspection 256 To obtain more visibility into negotiated TLS 1.3 parameters, a 257 middlebox can act as a (D)TLS 1.3 proxy. A middlebox can act as a 258 (D)TLS proxy for the IoT devices owned and managed by the IT team in 259 the Enterprise network and the (D)TLS proxy must meet the security 260 and privacy requirements of the organization. In other words, the 261 scope of middlebox acting as a (D)TLS proxy is restricted to 262 Enterprise network owning and managing the IoT devices. The 263 middlebox would have to follow the behaviour detailed in Section 9.3 264 of [RFC8446] to act as a compliant (D)TLS 1.3 proxy. 266 To further increase privacy, encrypted client hello 267 [I-D.ietf-tls-esni] prevents passive observation of the TLS Server 268 Name Indication extension. To effectively provide that privacy 269 protection, SNI encryption needs to be used in conjunction with DNS 270 encryption (e.g., DoH). A middlebox (e.g., firewall) passively 271 inspecting an encrypted SNI (D)TLS handshake cannot observe the 272 encrypted SNI nor observe the encrypted DNS traffic. 274 4.2. Encrypted DNS 276 A common usage pattern for certain type of IoT devices (e.g., light 277 bulb) is for it to "call home" to a service that resides on the 278 public Internet, where that service is referenced through a domain 279 name (A or AAAA record). As discussed in Manufacturer Usage 280 Description Specification [RFC8520], because these devices tend to 281 require access to very few sites, all other access should be 282 considered suspect. If an IoT device is pre-configured to use public 283 DoH/DoT server, the MUD policy enforcement point is moved to that 284 public server, which cannot enforce the MUD policy based on domain 285 names (Section 8 of [RFC8520]). If the DNS query is not accessible 286 for inspection, it becomes quite difficult for the infrastructure to 287 suspect anything. Thus the use of a public DoH/DoT server is 288 incompatible with MUD in general. A local DoH/DoT server is 289 necessary to allow MUD policy enforcement on the local network 290 [I-D.reddy-add-enterprise]. 292 5. (D)TLS Profile YANG Module 294 This document specifies a YANG module for representing (D)TLS 295 profile. The (D)TLS profile YANG module provides a method for 296 network security services to observe the (D)TLS profile parameters in 297 the (D)TLS handshake to permit intended use and to block malicious 298 behavior. This module uses the common YANG types defined in 299 [RFC6991], the rules defined in [RFC8519], and the cryptographic 300 types defined in [I-D.ietf-netconf-crypto-types]. See [RFC7925] for 301 (D)TLS 1.2 and [I-D.ietf-uta-tls13-iot-profile] for DTLS 1.3 302 recommendations related to IoT devices, and [RFC7525] for additional 303 (D)TLS 1.2 recommendations. 305 The (D)TLS parameters in each (D)TLS profile include the following: 307 o Profile name 309 o (D)TLS versions supported by the IoT device. 311 o List of supported cipher suites. For (D)TLS1.2, [RFC7925] 312 recommends AEAD ciphers for IoT devices. 314 o List of supported extension types 316 o List of trust anchor certificates used by the IoT device. If the 317 server certificate is signed by one of the trust anchors, the 318 middlebox continues with the connection as normal. Otherwise, the 319 middlebox will react as if the server certificate validation has 320 failed and takes appropriate action (e.g, block the (D)TLS 321 session). An IoT device can use a private trust anchor to 322 validate a server's certificate (e.g., the private trust anchor 323 can be preloaded at manufacturing time on the IoT device and the 324 IoT device fetches the firmware image from the Firmware server 325 whose certificate is signed by the private CA). This empowers the 326 middlebox to reject TLS sessions to servers that the IoT device 327 does not trust. 329 o List of SPKI pin set pre-configured on the client to validate 330 self-signed server certificates or raw public keys. A SPKI pin 331 set is a cryptographic digest to "pin" public key information in a 332 manner similar to HTTP Public Key Pinning (HPKP) [RFC7469]. If 333 SPKI pin set is present in the (D)TLS profile of a IoT device and 334 the server certificate does not pass the PKIX certification path 335 validation, the middlebox computes the SPKI Fingerprint for the 336 public key found in the server's certificate (or in the raw public 337 key, if the server provides that instead). If a computed 338 fingerprint exactly matches one of the SPKI pin sets in the (D)TLS 339 profile, the middlebox continues with the connection as normal. 340 Otherwise, the middlebox will act on the SPKI validation failure 341 and takes appropriate action. 343 o Cryptographic hash algorithm used to generate the SPKI pinsets 345 o List of pre-shared key exchange modes 347 o List of named groups (DHE or ECDHE) supported by the client 349 o List signature algorithms the client can validate in X.509 server 350 certificates 352 o List signature algorithms the client is willing to accept for 353 CertificateVerify message (Section 4.2.3 of [RFC8446]). For 354 example, a TLS client implementation can support different sets of 355 algorithms for certificates and in TLS to signal the capabilities 356 in "signature_algorithms_cert" and "signature_algorithms" 357 extensions. 359 o List of supported application protocols (e.g., h3, h2, http/1.1 360 etc.) 362 o List of certificate compression algorithms (defined in 363 [I-D.ietf-tls-certificate-compression]) 365 o List of the distinguished names [X501] of acceptable certificate 366 authorities, represented in DER-encoded format [X690] (defined in 367 Section 4.2.4 of [RFC8446]) 369 GREASE [RFC8701] sends random values on TLS parameters to ensure 370 future extensibility of TLS extensions. Similar random values might 371 be extended to other TLS parameters. Thus, the (D)TLS profile 372 parameters defined in the YANG module by this document MUST NOT 373 include the GREASE values for extension types, named groups, 374 signature algorithms, (D)TLS versions, pre-shared key exchange modes, 375 cipher suites and for any other TLS parameters defined in future 376 RFCs. 378 The (D)TLS profile does not include parameters like compression 379 methods for data compression, [RFC7525] recommends disabling TLS- 380 level compression to prevent compression-related attacks. In TLS 381 1.3, only the "null" compression method is allowed (Section 4.1.2 of 382 [RFC8446]). 384 Note: The TLS and DTLS IANA registries are available from 385 386 and . The values for all the parameters in the 388 YANG module excluding the supported_versions parameter are defined in 389 the TLS and DTLS IANA registries. The TLS and DTLS IANA registry 390 does not maintain (D)TLS version numbers. 392 5.1. Tree Structure 394 This document augments the "ietf-mud" MUD YANG module defined in 395 [RFC8520] for signaling the IoT device (D)TLS profile. This document 396 defines the YANG module "iana-opsawg-mud-tls-profile", which has the 397 following tree structure: 399 module: iana-opsawg-mud-tls-profile 400 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: 401 +--rw client-profile 402 +--rw tls-dtls-profiles* [profile-name] 403 +--rw profile-name string 404 +--rw supported_tls_versions* tls-version 405 +--rw supported_dtls_versions* dtls-version 406 +--rw cipher-suites* [cipher aead] 407 | +--rw cipher cipher-algorithm 408 | +--rw aead aead-algorithm 409 +--rw extension-types* extension-type 410 +--rw acceptlist-ta-certs* ct:trust-anchor-cert-cms 411 +--rw SPKI 412 | +--rw SPKI-pin-sets* SPKI-pin-set 413 | +--rw SPKI-hash-algorithm? iha:hash-algorithm-type 414 +--rw psk-key-exchange-modes* psk-key-exchange-mode {tls-1_3 or dtls-1_3}? 415 +--rw supported-groups* supported-group 416 +--rw signature-algorithms-cert* signature-algorithm {tls-1_3 or dtls-1_3}? 417 +--rw signature-algorithms* signature-algorithm 418 +--rw application-protocols* application-protocol 419 +--rw cert-compression-algorithms* cert-compression-algorithm {tls-1_3 or dtls-1_3}? 420 +--rw certificate_authorities* certificate_authority {tls-1_3 or dtls-1_3}? 422 5.2. YANG Module 424 file "iana-opsawg-mud-tls-profile@2020-09-25.yang" 425 module iana-opsawg-mud-tls-profile { 426 yang-version 1.1; 427 namespace "urn:ietf:params:xml:ns:yang:iana-opsawg-mud-tls-profile"; 428 prefix mud-tls-profile; 430 import ietf-crypto-types { 431 prefix ct; 432 reference "draft-ietf-netconf-crypto-types-01: 433 Common YANG Data Types for Cryptography"; 434 } 436 import iana-hash-algs { 437 prefix iha; 438 reference 439 "RFC XXXX: Common YANG Data Types for Hash algorithms"; 440 } 442 import ietf-access-control-list { 443 prefix acl; 444 reference 445 "RFC 8519: YANG Data Model for Network Access 446 Control Lists (ACLs)"; 447 } 449 organization 450 "IETF Operations and Management Area Working Group Working Group"; 451 contact 452 "Editor: Konda, Tirumaleswar Reddy 453 "; 455 description 456 "This module contains YANG definition for the IoT device 457 (D)TLS profile. 459 Copyright (c) 2019 IETF Trust and the persons identified as 460 authors of the code. All rights reserved. 462 Redistribution and use in source and binary forms, with or 463 without modification, is permitted pursuant to, and subject 464 to the license terms contained in, the Simplified BSD License 465 set forth in Section 4.c of the IETF Trust's Legal Provisions 466 Relating to IETF Documents 467 (http://trustee.ietf.org/license-info). 468 This version of this YANG module is part of RFC XXXX; see 469 the RFC itself for full legal notices."; 471 revision 2019-06-12 { 472 description 473 "Initial revision"; 474 } 476 typedef extension-type { 477 type uint16; 478 description "Extension type"; 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 psk-key-exchange-mode { 497 type uint8; 498 description "pre-shared key exchange mode"; 499 } 501 typedef client-public-key-length { 502 type uint8; 503 description "client public key length"; 504 } 506 typedef application-protocol { 507 type string; 508 description "application protocol"; 509 } 511 typedef cert-compression-algorithm { 512 type uint16; 513 description "certificate compression algorithm"; 514 } 515 typedef certificate_authority { 516 type binary; 517 description "Distinguished Name of Certificate authority"; 518 } 520 typedef cipher-algorithm { 521 type uint8; 522 description "Cipher Algorithm"; 523 } 525 typedef aead-algorithm { 526 type uint8; 527 description "AEAD Algorithm"; 528 } 530 typedef tls-version { 531 type enumeration { 532 enum tls-1.2 { 533 value 1; 534 description 535 "TLS Protocol Version 1.2."; 536 reference 537 "RFC 5246: The Transport Layer Security (TLS) Protocol 538 Version 1.2"; 539 } 540 enum tls-1.3 { 541 value 2; 542 description 543 "TLS Protocol Version 1.3."; 544 reference 545 "RFC 8446: The Transport Layer Security (TLS) Protocol 546 Version 1.3"; 547 } 548 } 549 description 550 "Indicates the TLS version."; 551 } 553 typedef dtls-version { 554 type enumeration { 555 enum dtls-1.2 { 556 value 1; 557 description 558 "DTLS Protocol Version 1.2."; 559 reference 560 "RFC 6346: Datagram Transport Layer Security 1.2"; 561 } 562 enum dtls-1.3 { 563 value 2; 564 description 565 "DTLS Protocol Version 1.3."; 566 reference 567 "draft-ietf-tls-dtls13: Datagram Transport Layer Security 1.3"; 568 } 569 } 570 description 571 "Indicates the DTLS version."; 572 } 574 feature tls-1_2 { 575 description 576 "TLS Protocol Version 1.2 is supported."; 577 reference 578 "RFC 5246: The Transport Layer Security (TLS) Protocol 579 Version 1.2"; 580 } 582 feature tls-1_3 { 583 description 584 "TLS Protocol Version 1.3 is supported."; 585 reference 586 "RFC 8446: The Transport Layer Security (TLS) Protocol 587 Version 1.3"; 588 } 590 feature dtls-1_2 { 591 description 592 "DTLS Protocol Version 1.2 is supported."; 593 reference 594 "RFC 6346: Datagram Transport Layer Security Version 1.2"; 595 } 597 feature dtls-1_3 { 598 description 599 "DTLS Protocol Version 1.3 is supported."; 600 reference 601 "draft-ietf-tls-dtls13: Datagram Transport Layer Security 1.3"; 602 } 604 grouping client-profile { 605 description 606 "A grouping for (D)TLS profiles."; 607 container client-profile { 608 list tls-dtls-profiles { 609 key "profile-name"; 610 description 611 "A list of (D)TLS version profiles supported by the client."; 612 leaf profile-name { 613 type string { 614 length "1..64"; 615 } 616 description 617 "The name of (D)TLS profile; space and special 618 characters are not allowed."; 619 } 620 leaf-list supported_versions { 621 type uint16; 622 description 623 "(D)TLS versions supported by the client"; 624 } 625 list cipher-suites { 626 key "cipher aead"; 627 leaf cipher { 628 type cipher-algorithm; 629 description "Cipher"; 630 } 631 leaf aead { 632 type aead-algorithm; 633 description "AEAD"; 634 } 635 description "Cipher Suites"; 636 } 637 leaf-list extension-types { 638 type extension-type; 639 description "Extension Types"; 640 } 641 leaf-list acceptlist-ta-certs { 642 type ct:trust-anchor-cert-cms; 643 description 644 "A list of trust anchor certificates used by the client."; 645 } 646 container SPKI { 647 leaf-list SPKI-pin-sets { 648 type SPKI-pin-set; 649 description 650 "A list of SPKI pin sets pre-configured on the client 651 to validate self-signed server certificate or 652 raw public key."; 653 } 654 leaf SPKI-hash-algorithm { 655 type iha:hash-algorithm-type; 656 description 657 "cryptographic hash algorithm used to generate the 658 SPKI pinset."; 660 } 661 } 662 leaf-list psk-key-exchange-modes { 663 if-feature "tls-1_3 or dtls-1_3"; 664 type psk-key-exchange-mode; 665 description 666 "pre-shared key exchange modes"; 667 } 668 leaf-list supported-groups { 669 type supported-group; 670 description 671 "A list of named groups supported by the client."; 672 } 673 leaf-list signature-algorithms-cert { 674 if-feature "tls-1_3 or dtls-1_3"; 675 type signature-algorithm; 676 description 677 "A list signature algorithms the client can validate 678 in X.509 certificates."; 679 } 680 leaf-list signature-algorithms { 681 type signature-algorithm; 682 description 683 "A list signature algorithms the client can validate 684 in the CertificateVerify message."; 685 } 686 leaf-list application-protocols { 687 type application-protocol; 688 description 689 "A list application protocols supported by the client"; 690 } 691 leaf-list cert-compression-algorithms { 692 if-feature "tls-1_3 or dtls-1_3"; 693 type cert-compression-algorithm; 694 description 695 "A list certificate compression algorithms 696 supported by the client"; 697 } 698 leaf-list certificate_authorities { 699 if-feature "tls-1_3 or dtls-1_3"; 700 type certificate_authority; 701 description 702 "A list of the distinguished names of certificate authorities 703 acceptable to the client"; 704 } 705 } 706 } 707 } 708 augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" { 709 description 710 "MUD (D)TLS specific matches."; 711 uses client-profile; 712 } 713 } 715 6. Processing of the MUD (D)TLS Profile 717 The following text outlines the rules for a network security service 718 (e.g., firewall) to follow to process the MUD (D)TLS Profile: 720 o If the (D)TLS parameter observed in a (D)TLS session is not 721 specified in the MUD (D)TLS profile and the parameter is 722 recognized by the firewall, it can identify unexpected (D)TLS 723 usage, which can indicate the presence of unauthorized software or 724 malware on an endpoint. The firewall can take several actions 725 like block the (D)TLS session or raise an alert to quarantine and 726 remediate the compromised device. For example, if the cipher 727 suite TLS_RSA_WITH_AES_128_CBC_SHA in the ClientHello message is 728 not specified in the MUD (D)TLS profile and the cipher suite is 729 recognized by the firewall, it can identify unexpected TLS usage. 731 o If the (D)TLS parameter observed in a (D)TLS session is not 732 specified in the MUD (D)TLS profile and the (D)TLS parameter is 733 not recognized by the firewall, it can ignore the unrecognized 734 parameter and the correct behavior is not to block the (D)TLS 735 session. The behaviour is functionally equivalent to the 736 description in Section 9.3 of [RFC8446] to ignore all unrecognized 737 cipher suites, extensions, and other parameters. For example, if 738 the cipher suite TLS_CHACHA20_POLY1305_SHA256 in the ClientHello 739 message is not specified in the MUD (D)TLS profile and the cipher 740 suite is not recognized by the firewall, it can ignore the 741 unrecognized cipher suite. 743 o Deployments update at different rates, so an updated MUD (D)TLS 744 profile may support newer parameters. If the firewall does not 745 recognize the newer parameters, an alert should be triggered to 746 the firewall vendor and the IoT device owner or administrator. A 747 firewall must be readily updatable, so that when ossification 748 problems are discovered, they can be addressed quickly. Most 749 importantly, if the firewall is not readily updatable, its 750 efficacy to identify emerging malware will decrease with time. 751 For example, if the cipher suite TLS_AES_128_CCM_8_SHA256 in the 752 ClientHello message is specified in the MUD (D)TLS profile and the 753 cipher suite is not recognized by the firewall, an alert will be 754 triggered. 756 7. MUD File Example 758 The example below contains (D)TLS profile parameters for a IoT device 759 used to reach servers listening on port 443 using TCP transport. 760 JSON encoding of YANG modelled data [RFC7951] is used to illustrate 761 the example. 763 { 764 "ietf-mud:mud": { 765 "mud-version": 1, 766 "mud-url": "https://example.com/IoTDevice", 767 "last-update": "2019-18-06T03:56:40.105+10:00", 768 "cache-validity": 100, 769 "is-supported": true, 770 "systeminfo": "IoT device name", 771 "from-device-policy": { 772 "access-lists": { 773 "access-list": [ 774 { 775 "name": "mud-7500-profile" 776 } 777 ] 778 } 779 }, 780 "ietf-access-control-list:acls": { 781 "acl": [ 782 { 783 "name": "mud-7500-profile", 784 "type": "ipv6-acl-type", 785 "aces": { 786 "ace": [ 787 { 788 "name": "cl0-frdev", 789 "matches": { 790 "ipv6": { 791 "protocol": 6 792 }, 793 "tcp": { 794 "ietf-mud:direction-initiated": "from-device", 795 "destination-port": { 796 "operator": "eq", 797 "port": 443 798 } 799 }, 800 "iana-opsawg-mud-tls-profile:client-profile" : { 801 "tls-dtls-profiles" : [ 802 { 803 "supported-tls-versions" : [2], 804 "cipher-suites" : [ 805 { 806 "cipher": 19, 807 "aead": 1 808 }, 809 { 810 "cipher": 19, 811 "aead": 2 812 } 813 ], 814 "extension-types" : [10,11,13,16,24], 815 "supported-groups" : [29] 816 } 817 ] 818 }, 819 "actions": { 820 "forwarding": "accept" 821 } 822 } 823 } 824 ] 825 } 826 } 827 ] 828 } 829 } 830 } 832 The following illustrates the example scenarios for processing the 833 above profile: 835 o If the extension type "encrypt_then_mac" (code point 22) [RFC7366] 836 in the ClientHello message is recognized by the firewall, it can 837 identify unexpected TLS usage. 839 o If the extension type "token_binding" (code point 24) [RFC8472] in 840 the ClientHello message is not recognized by the firewall, it can 841 ignore the unrecognized extension. Because the extension type 842 token_binding is specified in the profile, an alert will be 843 triggered to the firewall vendor and the IoT device owner or 844 administrator to notify the firewall is not up to date. 846 8. Security Considerations 848 Security considerations in [RFC8520] need to be taken into 849 consideration. Although it is challenging for a malware to mimic the 850 TLS behavior of various IoT device types and IoT device models from 851 several manufacturers, malicious agents have a very low probability 852 of using the same (D)TLS profile parameters as legitimate agents on 853 the IoT device to evade detection. Network security services should 854 also rely on contextual network data to detect false negatives. In 855 order to detect such malicious flows, anomaly detection (deep 856 learning techniques on network data) can be used to detect malicious 857 agents using the same (D)TLS profile parameters as legitimate agent 858 on the IoT device. In anomaly detection, the main idea is to 859 maintain rigorous learning of "normal" behavior and where an 860 "anomaly" (or an attack) is identified and categorized based on the 861 knowledge about the normal behavior and a deviation from this normal 862 behavior. 864 9. Privacy Considerations 866 Privacy considerations discussed in Section 16 of [RFC8520] to not 867 reveal the MUD URL to an atacker need to be taken into consideration. 868 The MUD URL can be stored in Trusted Execution Environment (TEE) for 869 secure operation, enhanced data security, and prevent exposure to 870 unauthorized software. 872 The middlebox acting as a (D)TLS proxy must immediately delete the 873 decrypted data upon completing any necessary inspection functions. 874 TLS proxy potentially has access to a user's PII (Personally 875 identifiable information) and PHI (Protected Health Information). 876 The TLS proxy must not store, process or modify PII data. For 877 example, IT administrator can configure the middlebox to bypass 878 payload inspection for a connection destined to a specific service 879 due to privacy compliance requirements. In addition, mechanisms 880 based on object security can be used by IoT devices to enable end-to- 881 end security and the middlebox will not have any access to the packet 882 data. For example, Object Security for Constrained RESTful 883 Environments (OSCORE) [RFC8613] is a proposal that protects CoAP 884 messages by wrapping them in the COSE format [RFC8152]. 886 10. IANA Considerations 888 Each normative YANG module MUST be registered in both the "IETF XML 889 Registry" [RFC3688] and the "YANG Module Names" registry [RFC6020]. 891 This document requests IANA to register the following URIs in the 892 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 894 URI: urn:ietf:params:xml:ns:yang:iana-opsawg-mud-tls-profile 895 Registrant Contact: The IESG. 896 XML: N/A; the requested URI is an XML namespace. 898 This document requests IANA to register the following YANG modules in 899 the "YANG Module Names" subregistry [RFC6020] within the "YANG 900 Parameters" registry. IANA is requested to create an IANA-maintained 901 YANG Module called "iana-opsawg-mud-tls-profile", based on the 902 contents of Section 5, which will allow for new (D)TLS parameters and 903 (D)TLS versions. The registration procedure will be Expert Review or 904 Specification Required, as defined by [RFC8126]. 906 name: iana-opsawg-mud-tls-profile 907 namespace: urn:ietf:params:xml:ns:yang:iana-opsawg-mud-tls-profile 908 maintained by IANA: Y 909 prefix: mud-tls-profile 910 reference: RFC XXXX 912 11. Acknowledgments 914 Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson, 915 Piyush Joshi, Eliot Lear, Harsha Joshi, Qin Wu, Mohamed Boucadair, 916 Ben Schwartz, Eric Rescorla, Panwei William, Nick Lamb and Nick 917 Harper for the discussion and comments. 919 12. References 921 12.1. Normative References 923 [I-D.ietf-netconf-crypto-types] 924 Watsen, K., "YANG Data Types and Groupings for 925 Cryptography", draft-ietf-netconf-crypto-types-18 (work in 926 progress), August 2020. 928 [I-D.ietf-tls-certificate-compression] 929 Ghedini, A. and V. Vasiliev, "TLS Certificate 930 Compression", draft-ietf-tls-certificate-compression-10 931 (work in progress), January 2020. 933 [I-D.ietf-tls-dtls13] 934 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 935 Datagram Transport Layer Security (DTLS) Protocol Version 936 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 937 2020. 939 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 940 Requirement Levels", BCP 14, RFC 2119, 941 DOI 10.17487/RFC2119, March 1997, 942 . 944 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 945 DOI 10.17487/RFC3688, January 2004, 946 . 948 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 949 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 950 January 2012, . 952 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 953 RFC 6991, DOI 10.17487/RFC6991, July 2013, 954 . 956 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 957 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 958 May 2017, . 960 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 961 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 962 . 964 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 965 "YANG Data Model for Network Access Control Lists (ACLs)", 966 RFC 8519, DOI 10.17487/RFC8519, March 2019, 967 . 969 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 970 Sustain Extensibility (GREASE) to TLS Extensibility", 971 RFC 8701, DOI 10.17487/RFC8701, January 2020, 972 . 974 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 975 Specification of Basic Encoding Rules (BER), Canonical 976 Encoding Rules (CER) and Distinguished Encoding Rules 977 (DER)", ISO/IEC 8825-1:2002, 2002. 979 12.2. Informative References 981 [cryto-vulnerability] 982 Perez, B., "Exploiting the Windows CryptoAPI 983 Vulnerability", January 2020, 984 . 987 [I-D.ietf-tls-esni] 988 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 989 Encrypted Client Hello", draft-ietf-tls-esni-07 (work in 990 progress), June 2020. 992 [I-D.ietf-uta-tls13-iot-profile] 993 Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for 994 the Internet of Things", draft-ietf-uta-tls13-iot- 995 profile-00 (work in progress), June 2020. 997 [I-D.reddy-add-enterprise] 998 Reddy.K, T. and D. Wing, "DNS-over-HTTPS and DNS-over-TLS 999 Server Deployment Considerations for Enterprise Networks", 1000 draft-reddy-add-enterprise-00 (work in progress), June 1001 2020. 1003 [malware] Anderson, B., Paul, S., and D. McGrew, "Deciphering 1004 Malware's use of TLS (without Decryption)", July 2016, 1005 . 1007 [malware-doh] 1008 Cimpanu, C., "First-ever malware strain spotted abusing 1009 new DoH (DNS over HTTPS) protocol", July 2019, 1010 . 1013 [malware-tls] 1014 Anderson, B. and D. McGrew, "TLS Beyond the Browser: 1015 Combining End Host and Network Data to Understand 1016 Application Behavior", October 2019, 1017 . 1019 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1020 the Network Configuration Protocol (NETCONF)", RFC 6020, 1021 DOI 10.17487/RFC6020, October 2010, 1022 . 1024 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 1025 Security (TLS) and Datagram Transport Layer Security 1026 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 1027 . 1029 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1030 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1031 2015, . 1033 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1034 "Recommendations for Secure Use of Transport Layer 1035 Security (TLS) and Datagram Transport Layer Security 1036 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1037 2015, . 1039 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1040 Security (TLS) / Datagram Transport Layer Security (DTLS) 1041 Profiles for the Internet of Things", RFC 7925, 1042 DOI 10.17487/RFC7925, July 2016, 1043 . 1045 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1046 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1047 . 1049 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1050 Writing an IANA Considerations Section in RFCs", BCP 26, 1051 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1052 . 1054 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1055 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1056 . 1058 [RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport 1059 Layer Security (TLS) Extension for Token Binding Protocol 1060 Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 1061 2018, . 1063 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1064 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1065 . 1067 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1068 Description Specification", RFC 8520, 1069 DOI 10.17487/RFC8520, March 2019, 1070 . 1072 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1073 Things (IoT) Security: State of the Art and Challenges", 1074 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1075 . 1077 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1078 "Object Security for Constrained RESTful Environments 1079 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1080 . 1082 [X501] "Information Technology - Open Systems Interconnection - 1083 The Directory: Models", ITU-T X.501, 1993. 1085 Authors' Addresses 1086 Tirumaleswar Reddy 1087 McAfee, Inc. 1088 Embassy Golf Link Business Park 1089 Bangalore, Karnataka 560071 1090 India 1092 Email: kondtir@gmail.com 1094 Dan Wing 1095 Citrix Systems, Inc. 1096 4988 Great America Pkwy 1097 Santa Clara, CA 95054 1098 USA 1100 Email: danwing@gmail.com 1102 Blake Anderson 1103 Cisco Systems, Inc. 1104 170 West Tasman Dr 1105 San Jose, CA 95134 1106 USA 1108 Email: blake.anderson@cisco.com