MUD (D)TLS profiles for
IoT devicesMcAfee, Inc.Embassy Golf Link Business ParkBangaloreKarnataka560071Indiakondtir@gmail.comCitrix Systems, Inc.4988 Great America PkwySanta ClaraCA95054USAdanwing@gmail.comCisco Systems, Inc.170 West Tasman DrSan JoseCA95134USAblake.anderson@cisco.comOPSWG WGThis memo extends Manufacturer Usage Description (MUD) to incorporate
(D)TLS profile parameters. This allows a network element to identify
unexpected (D)TLS usage, which can indicate the presence of unauthorized
software or malware on an endpoint.Encryption is necessary to protect the privacy of end users using IoT
devices. In a network setting, TLS and
DTLS are the dominant
protocols providing encryption for IoT device traffic. Unfortunately, in
conjunction with IoT applications' rise of encryption, malware is also
using encryption which thwarts network-based analysis such as deep
packet inspection (DPI). Other mechanisms are needed to notice malware
is running on the IoT device.Malware frequently uses its own libraries for its activities, and
those libraries are re-used much like any other software engineering
project. Research indicates there are
observable differences in how malware uses encryption compared with how
non-malware uses encryption. There are several interesting findings
specific to DTLS and TLS which were found common to malware: Older and weaker cryptographic parameters (e.g.,
TLS_RSA_WITH_RC4_128_SHA).TLS SNI and server certificates are composed of subjects with
characteristics of a domain generation algorithm (DGA) (e.g.,
www.33mhwt2j.net).Higher use of self-signed certificates compared with typical
legitimate software.Discrepancies in the server name indication (SNI) TLS extension
in the ClientHello message and the DNS names in the
SubjectAltName(SAN) X.509 extension in the server certificate
message.Discrepancies in the key exchange algorithm and the client public
key length in comparison with legitimate flows. As a reminder,
Client Key Exchange message has been removed from TLS 1.3.Lower diversity in TLS client advertised TLS extensions compared
to legitimate clients.Malware using privacy enhancing technologies like Tor, Psiphon
and Ultrasurf (see ) and, evasion
techniques such as ClientHello randomization to evade detection in
order to continue exploiting the end user.Malware using DNS-over-HTTPS to
avoid detection by malware DNS filtering service (). Malware agent may not use the
DNS-over-HTTPS server provided by the local network.If observable (D)TLS profile parameters are used, the following
functions are possible which have a favorable impact on network
security:Permit intended DTLS or TLS use and block malicious DTLS or TLS
use. This is superior to the layer 3 and layer 4 ACLs of
Manufacturer Usage Description Specification (MUD) which are not suitable for broad
communication patterns.Ensure TLS certificates are valid. Several TLS deployments have
been vulnerable to active Man-In-The-Middle (MITM) attacks because
of the lack of certificate validation or vulnerability in the
certificate validation function (see ). By observing (D)TLS profile
parameters, a network element can detect when the TLS SNI mismatches
the SubjectAltName and when the server's certificate is invalid. In
TLS 1.2, the ClientHello, ServerHello and Certificate messages are
all sent in clear-text, however in TLS 1.3, the Certificate message
is encrypted thereby hiding the server identity from any
intermediary. In TLS 1.3, the middle-box needs to act as a TLS proxy
to validate the server certificate and to detect TLS SNI mismatch
with the server certificate.Support new communication patterns. An IoT device can learn a new
capability, and the new capability can change the way the IoT device
communicates with other devices located in the local network and
Internet. There would be an inaccurate policy if an IoT device
rapidly changes the IP addresses and domain names it communicates
with while the MUD ACLs were slower to update. In such a case,
observable (D)TLS profile parameters can be used to permit intended
use and to block malicious behaviour from the IoT device.This document extends MUD to model
observable (D)TLS profile parameters. Using these (D)TLS profile
parameters, an active MUD-enforcing firewall can identify MUD
non-compliant (D)TLS behavior indicating outdated cryptography or
malware. This detection can prevent malware downloads, block access to
malicious domains, enforce use of strong ciphers, stop data
exfiltration, etc. In addition, organizations may have policies around
acceptable ciphers and certificates on the websites the IoT devices
connect to. Examples include no use of old and less secure versions of
TLS, no use of self-signed certificates, deny-list or accept-list of
Certificate Authorities, valid certificate expiration time, etc. These
policies can be enforced by observing the (D)TLS profile parameters.
Enterprise firewalls can use the IoT device's (D)TLS profile parameters
to identify legitimate flows by observing (D)TLS sessions, and can make
inferences to permit legitimate flows and to block malicious or insecure
flows. The proposed technique is also suitable in deployments where
decryption techniques are not ideal due to privacy concerns,
non-cooperating end-points and expense.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and
only when, they appear in all capitals, as shown here."(D)TLS" is used for statements that apply to both Transport Layer
Security and Datagram Transport Layer
Security . Specific terms are used for any
statement that applies to either protocol alone.'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS.In Enterprise networks, protection and detection are typically done
both on end hosts and in the network. Host agents have deep visibility
on the devices where they are installed, whereas the network has broader
visibility. Installing host agents may not be a viable option on IoT
devices, and network-based security is an efficient means to protect
such IoT devices. (D)TLS profile parameters of IoT device can be used by
middle-boxes to detect and block malware communication, while at the
same time preserving the privacy of legitimate uses of encryption.
Middle-boxes need not proxy (D)TLS but can passively observe the
parameters of (D)TLS handshakes from IoT devices and gain good
visibility into TLS 1.0 to 1.2 parameters and partial visibility into
TLS 1.3 parameters. Malicious agents can try to use the (D)TLS profile
parameters of legitimate agents to evade detection, but it becomes a
challenge to mimic the behavior of various IoT device types and IoT
device models from several manufacturers. In other words, malware
developers will have to develop malicious agents per IoT device type,
manufacturer and model, infect the device with the tailored malware
agent and will have keep up with updates to the device's (D)TLS profile
parameters over time. Further, the malware's command and control server
certificates need to be signed by the same certifying authorities
trusted by the IoT devices. Typically, IoT devices have an
infrastructure that supports a rapid deployment of updates, and malware
agents will have a near-impossible task of similarly deploying updates
and continuing to mimic the TLS behavior of the IoT device it has
infected.The compromised IoT devices are typically used for launching DDoS
attacks (Section 3 of ). Some of the DDoS
attacks like Slowloris and Transport Layer Security (TLS) re-negotiation
can be detected by observing the (D)TLS profile parameters. For example,
the victim's server certificate need not be signed by the same
certifying authorities trusted by the IoT device.In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since
all (D)TLS handshake messages excluding the ClientHello message are
encrypted. (D)TLS 1.3 has introduced new extensions in the handshake
record layers called Encrypted Extensions. Using these extensions
handshake messages will be encrypted and network devices (such as a
firewall) are incapable deciphering the handshake, thus cannot view the
server certificate. However, the ClientHello and ServerHello still have
some fields visible, such as the list of supported versions, named
groups, cipher suites, signature algorithms and extensions in
ClientHello and, chosen cipher in the ServerHello. For instance, if the
malware uses evasion techniques like ClientHello randomization, the
observable list of cipher suites and extensions offered by the malware
agent in the ClientHello message will not match the list of cipher
suites and extensions offered by the legitimate client in the
ClientHello message, and the middle-box can block malicious flows
without acting as a (D)TLS 1.3 proxy.To obtain more visibility into negotiated TLS 1.3 parameters, a
middle-box can act as a (D)TLS 1.3 proxy. A middle-box can act as a
(D)TLS proxy for the IoT devices owned and managed by the IT team in
the Enterprise network and the (D)TLS proxy must meet the security and
privacy requirements of the organization. In other words, the scope of
middle-box acting as a (D)TLS proxy is restricted to Enterprise
network owning and managing the IoT devices. The middle-box MUST
follow the behaviour explained in Section 9.3 of to act as a compliant (D)TLS 1.3 proxy.To function as a (D)TLS proxy the middle-box creates a signed
certificate using itself as a certificate authority. That certificate
authority has to be trusted by the (D)TLS client. The IoT device needs
to be configured with the middle-box's CA certificate as Explicit
Trust Anchor database entry to validate the server certificate. The
mechanism to configure the IoT device with the middle-box's CA
certificate is out of scope. The middle-box uses the
"supported_versions" TLS extension (defined in TLS 1.3 to negotiate
the supported TLS versions between client and server) to determine the
TLS version. During the (D)TLS handshake, If (D)TLS version 1.3 is
used, the middle-box ((D)TLS proxy) modifies the certificate provided
by the server and signs it with the private key from the local CA
certificate. The middle-box has visibility into further exchanges
between the IoT device and server which enables it to inspect the
(D)TLS 1.3 handshake, enforce the MUD (D)TLS profile and can inspect
subsequent network traffic. The IoT device uses the Explicit Trust
Anchor database to validate the server certificate.To increase privacy, encrypted SNI (ESNI, ) prevents passive
observation of the TLS Server Name Indication extension. To
effectively provide that privacy protection, SNI encryption needs to
be used in conjunction with DNS encryption (e.g., DNS-over-TLS (DoT)
or DNS-over-HTTPS (DoH) ). A middle-box (e.g., firewall) passively
inspecting an encrypted SNI (D)TLS handshake cannot observe the
encrypted SNI nor observe the encrypted DNS traffic. If an IoT device
is pre-configured to use public DoH/DoT servers, that middle-box needs
to act as a DoH/DoT proxy and replace the ECH configuration in the
"echconfig" SvcParamKey (Section 6.3 of ) with the middle
box’s ECH configuration. Instead of an unappealing DoH/DoT
proxy, the IoT device can be bootstrapped to discover and authenticate
DoH/DoT servers provided by a local network by making use of one of
the mechanisms described in Section 4 of . The local DoH/DoT server
replaces the ECH configuration in the "echconfig" SvcParamKey with the
middle box’s ECH configuration.A common usage pattern for certain type of IoT devices (e.g., light
bulb) is for it to "call home" to a service that resides on the public
Internet, where that service is referenced through a domain name (A or
AAAA record). As discussed in Manufacturer Usage Description
Specification , because these devices
tend to require access to very few sites, all other access should be
considered suspect. If an IoT device is pre-configured to use public
DoH/DoT server, the MUD policy enforcement point is moved to that
public server, which cannot enforce the MUD policy based on domain
names (Section 8 of ). If the DNS query
is not accessible for inspection, it becomes quite difficult for the
infrastructure to suspect anything. Thus the use of a public DoH/DoT
server is incompatible with MUD in general. A local DoH/DoT server is
necessary to allow MUD policy enforcement on the local network.This document specifies a YANG module for representing (D)TLS
profile. The (D)TLS profile YANG module provides a method for firewall
to observe the (D)TLS profile parameters in the (D)TLS handshake to
permit intended use and to block malicious behavior. This module uses
the common YANG types defined in , rules
defined in and cryptographic types
defined in .The (D)TLS profiles and the parameters in each (D)TLS profile include
the following:Profile name(D)TLS version in ClientHello.legacy_version(D)TLS versions supported by the IoT device. As a reminder,
"supported_versions" extension defined in (D)TLS 1.3 is used by the
client to indicate which versions of (D)TLS it supports and a client
is considered to be attempting to negotiate (D)TLS 1.3 if the
ClientHello contains a "supported_versions" extension with 0x0304
contained in its body.If GREASE (Generate Random
Extensions And Sustain Extensibility) values are offered by the
client or not.List of supported symmetric encryption algorithms. TLS 1.3
defines five cipher suites (Appendix B.4 of ), but most clients are continuing to offer
TLS 1.2 compatible cipher suites for backwards compatibility.List of supported compression methods for data compression. In
TLS 1.3, only the "null" compression method is allowed (Section
4.1.2 of ).List of supported extension typesList of trust anchor certificates used by the IoT device. If the
server certificate is signed by one of the trust anchors, the
middle-box continues with the connection as normal. Otherwise, the
middle-box will react as if the server certificate validation has
failed and takes appropriate action (e.g, block the (D)TLS session).
An IoT device can use a private trust anchor to validate a server's
certificate (e.g., the private trust anchor can be preloaded at
manufacturing time on the IoT device and the IoT device fetches the
firmware image from the Firmware server whose certificate is signed
by the private CA).List of SPKI pin set pre-configured on the client to validate
self-signed server certificates or raw public keys. A SPKI pin set
is a cryptographic digest to "pin" public key information in a
manner similar to HTTP Public Key Pinning (HPKP) . If SPKI pin set is present in the (D)TLS
profile of a IoT device and the server certificate does not pass the
PKIX certification path validation, the middle-box computes the SPKI
Fingerprint for the public key found in the server's certificate (or
in the raw public key, if the server provides that instead). If a
computed fingerprint exactly matches one of the SPKI pin sets in the
(D)TLS profile, the middle-box continues with the connection as
normal. Otherwise, the middle-box will act on the SPKI validation
failure and takes appropriate action.Cryptographic hash algorithm used to generate the SPKI
pinsetsList of pre-shared key exchange modesList of named groups (DHE or ECDHE) supported by the clientList signature algorithms the client can validate in X.509 server
certificatesList signature algorithms the client is willing to accept for
CertificateVerify message (Section 4.2.3 of ). For example, a TLS client implementation
can support different sets of algorithms for certificates and in TLS
to signal the capabilities in "signature_algorithms_cert" and
"signature_algorithms" extensions.List of supported application protocols (e.g., h3, h2, http/1.1
etc.)List of certificate compression algorithms (defined in )List of the distinguished names of
acceptable certificate authorities, represented in DER-encoded
format (defined in Section 4.2.4 of
)List of client key exchange algorithms and the client public key
lengths in versions prior to (D)TLS 1.3The (D)TLS profile parameters include the GREASE values for extension
types, named groups, signature algorithms, (D)TLS versions, pre-shared
key exchange modes and cipher suites, but normalized to the value 0x0a
to preserve ordering information. Note that the GREASE values are random
but their positions are deterministic (Section 5 of ) and peers will ignore these values and
interoperate.If the (D)TLS profile parameters are not observed in a (D)TLS session
from the IoT device, the default behaviour is to block the (D)TLS
session.Note: The TLS and DTLS IANA registries are available from .This document augments the "ietf-mud" MUD YANG module defined in
for signaling the IoT device (D)TLS
profile. This document defines the YANG module
"reddy-opsawg-mud-tls-profile", which has the following tree
structure:This example below contains (D)TLS profile parameters for a IoT
device used to reach servers listening on port 443 using TCP transport.
JSON encoding of YANG modelled data is
used to illustrate the example.Security considerations in need to be
taken into consideration. Although it is challenging for a malware to
mimic the TLS behavior of various IoT device types and IoT device models
from several manufacturers, malicious agents have a very low probabilty
of using the same (D)TLS profile parameters as legitimate agents on the
IoT device to evade detection. Network security services should also
rely on contextual network data to detect false negatives. In order to
detect such malicious flows, anomaly detection (deep learning techniques
on network data) can be used to detect malicious agents using the same
(D)TLS profile parameters as legitimate agent on the IoT device. In
anomaly detection, the main idea is to maintain rigorous learning of
"normal" behavior and where an "anomaly" (or an attack) is identified
and categorized based on the knowledge about the normal behavior and a
deviation from this normal behavior.The middle-box acting as a (D)TLS proxy must immediately delete the
decrypted data upon completing any necessary inspection functions. TLS
proxy potentially has access to a user's PII (Personally identifiable
information) and PHI (Protected Health Information). The TLS proxy must
not store, process or modify PII data. For example, IT administrator can
configure firewall to bypass payload inspection for a connection
destined to a specific service due to privacy compliance
requirements.This document requests IANA to register the following URIs in the
"ns" subregistry within the "IETF XML Registry" : Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson,
Piyush Joshi and Harsha Joshi for the discussion and comments.Information technology - ASN.1 encoding Rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)ITU-TDeciphering Malware’s use of TLS (without
Decryption)CiscoCiscoCiscoInformation Technology - Open Systems Interconnection - The
Directory: ModelsTLS Beyond the Browser: Combining End Host and Network Data
to Understand Application BehaviorCiscoCiscoExploiting the Windows CryptoAPI VulnerabilityCiscoFirst-ever malware strain spotted abusing new DoH (DNS over
HTTPS) protocolCisco