idnits 2.17.1 draft-reddy-opsawg-mud-tls-02.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 == Line 430 has weird spacing: '...warding ide...' -- The document date (January 16, 2020) is 1561 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 663 -- Looks like a reference, but probably isn't: '4865' on line 663 -- Looks like a reference, but probably isn't: '4866' on line 663 -- Looks like a reference, but probably isn't: '4867' on line 663 -- Looks like a reference, but probably isn't: '10' on line 664 -- Looks like a reference, but probably isn't: '29' on line 665 == 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 (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-34 == Outdated reference: A later version (-08) exists of draft-reddy-dprive-bootstrap-dns-server-06 Summary: 2 errors (**), 0 flaws (~~), 7 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: July 19, 2020 Citrix 6 B. Anderson 7 Cisco 8 January 16, 2020 10 MUD (D)TLS profiles for IoT devices 11 draft-reddy-opsawg-mud-tls-02 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 July 19, 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 . . . . . . . . . . 5 59 4.2. Encrypted SNI . . . . . . . . . . . . . . . . . . . . . . 7 60 5. (D)TLS profile YANG module . . . . . . . . . . . . . . . . . 7 61 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 9 62 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 14 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 66 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 69 10.2. Informative References . . . . . . . . . . . . . . . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 72 1. Introduction 74 Encryption is necessary to protect the privacy of end users using IoT 75 devices. In a network setting, TLS [RFC8446] and DTLS 76 [I-D.ietf-tls-dtls13] are the dominant protocols providing encryption 77 for IoT device traffic. Unfortunately, in conjunction with IoT 78 applications' rise of encryption, malware is also using encryption 79 which thwarts network-based analysis such as deep packet inspection 80 (DPI). Other mechanisms are needed to notice malware is running on 81 the IoT device. 83 Malware frequently uses its own libraries for its activities, and 84 those libraries are re-used much like any other software engineering 85 project. Research [malware] indicates there are observable 86 differences in how malware uses encryption compared with how non- 87 malware uses encryption. There are several interesting findings 88 specific to DTLS and TLS which were found common to malware: 90 o Older and weaker cryptographic parameters (e.g., 91 TLS_RSA_WITH_RC4_128_SHA). 93 o TLS SNI and server certificates are composed of subjects with 94 characteristics of a domain generation algorithm (DGA) (e.g., 95 www.33mhwt2j.net). 97 o Higher use of self-signed certificates compared with typical 98 legitimate software. 100 o Discrepancies in the server name indication (SNI) TLS extension in 101 the ClientHello message and the DNS names in the 102 SubjectAltName(SAN) X.509 extension in the server certificate 103 message. 105 o Discrepancies in the key exchange algorithm and the client public 106 key length in comparison with legitimate flows. As a reminder, 107 Client Key Exchange message has been removed from TLS 1.3. 109 o Lower diversity in TLS client advertised TLS extensions compared 110 to legitimate clients. 112 o Malware using privacy enhancing technologies like Tor, Psiphon and 113 Ultrasurf (see [malware-tls]) and, evasion techniques such as 114 ClientHello randomization to evade detection in order to continue 115 exploiting the end user. 117 If observable (D)TLS profile parameters are used, the following 118 functions are possible which have a favorable impact on network 119 security: 121 o Permit intended DTLS or TLS use and block malicious DTLS or TLS 122 use. This is superior to the layer 3 and layer 4 ACLs of 123 Manufacturer Usage Description Specification (MUD) [RFC8520] which 124 are not suitable for broad communication patterns. 126 o Ensure TLS certificates are valid. Several TLS deployments have 127 been vulnerable to active Man-In-The-Middle (MITM) attacks because 128 of the lack of certificate validation. By observing (D)TLS 129 profile parameters, a network element can detect when the TLS SNI 130 mismatches the SubjectAltName and when the server's certificate is 131 invalid. In TLS 1.2, the ClientHello, ServerHello and Certificate 132 messages are all sent in clear-text, however in TLS 1.3, the 133 Certificate message is encrypted thereby hiding the server 134 identity from any intermediary. In TLS 1.3, the middle-box needs 135 to act as a TLS proxy to validate the server certificate and to 136 detect TLS SNI mismatch with the server certificate. 138 o Support new communication patterns. An IoT device can learn a new 139 capability, and the new capability can change the way the IoT 140 device communicates with other devices located in the local 141 network and Internet. There would be an inaccurate policy if an 142 IoT device rapidly changes the IP addresses and domain names it 143 communicates with while the MUD ACLs were slower to update. In 144 such a case, observable (D)TLS profile parameters can be used to 145 permit intended use and to block malicious behaviour from the IoT 146 device. 148 This document extends MUD [RFC8520] to model observable (D)TLS 149 profile parameters. Using these (D)TLS profile parameters, an active 150 MUD-enforcing firewall can identify MUD non-compliant (D)TLS behavior 151 indicating outdated cryptography or malware. This detection can 152 prevent malware downloads, block access to malicious domains, enforce 153 use of strong ciphers, stop data exfiltration, etc. In addition, 154 organizations may have policies around acceptable ciphers and 155 certificates on the websites the IoT devices connect to. Examples 156 include no use of old and less secure versions of TLS, no use of 157 self-signed certificates, deny-list or accept-list of Certificate 158 Authorities, valid certificate expiration time, etc. These policies 159 can be enforced by observing the (D)TLS profile parameters. 160 Enterprise firewalls can use the IoT device's (D)TLS profile 161 parameters to identify legitimate flows by observing (D)TLS sessions, 162 and can make inferences to permit legitimate flows and to block 163 malicious or insecure flows. The proposed technique is also suitable 164 in deployments where decryption techniques are not ideal due to 165 privacy concerns, non-cooperating end-points and expense. 167 2. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in BCP 172 14 [RFC2119][RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 "(D)TLS" is used for statements that apply to both Transport Layer 176 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 177 Specific terms are used for any statement that applies to either 178 protocol alone. 180 3. Overview of MUD (D)TLS profiles for IoT devices 182 In Enterprise networks, protection and detection are typically done 183 both on end hosts and in the network. Host agents have deep 184 visibility on the devices where they are installed, whereas the 185 network has broader visibility. Installing host agents may not be a 186 viable option on IoT devices, and network-based security is an 187 efficient means to protect such IoT devices. (D)TLS profile 188 parameters of IoT device can be used by middle-boxes to detect and 189 block malware communication, while at the same time preserving the 190 privacy of legitimate uses of encryption. Middle-boxes need not 191 proxy (D)TLS but can passively observe the parameters of (D)TLS 192 handshakes from IoT devices and gain good visibility into TLS 1.0 to 193 1.2 parameters and partial visibility into TLS 1.3 parameters. 194 Malicious agents can try to use the (D)TLS profile parameters of 195 legitimate agents to evade detection, but it becomes a challenge to 196 mimic the behavior of various IoT device types and IoT device models 197 from several manufacturers. In other words, malware developers will 198 have to develop malicious agents per IoT device type, manufacturer 199 and model, infect the device with the tailored malware agent and will 200 have keep up with updates to the device's (D)TLS profile parameters 201 over time. Further, the malware's command and control server 202 certificates need to be signed by the same certifying authorities 203 trusted by the IoT devices. Typically, IoT devices have an 204 infrastructure that supports a rapid deployment of updates, and 205 malware agents will have a near-impossible task of similarly 206 deploying updates and continuing to mimic the TLS behavior of the IoT 207 device it has infected. 209 The compromised IoT devices are typically used for launching DDoS 210 attacks (Section 3 of [RFC8576]). Some of the DDoS attacks like 211 Slowloris and Transport Layer Security (TLS) re-negotiation can be 212 detected by observing the (D)TLS profile parameters. For example, 213 the victim's server certificate need not be signed by the same 214 certifying authorities trusted by the IoT device. 216 4. (D)TLS 1.3 handshake 218 In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since 219 all (D)TLS handshake messages excluding the ClientHello message are 220 encrypted. (D)TLS 1.3 has introduced new extensions in the handshake 221 record layers called Encrypted Extensions. Using these extensions 222 handshake messages will be encrypted and network devices (such as a 223 firewall) are incapable deciphering the handshake, thus cannot view 224 the server certificate. However, the ClientHello and ServerHello 225 still have some fields visible, such as the list of supported 226 versions, named groups, cipher suites, signature algorithms and 227 extensions in ClientHello and, chosen cipher in the ServerHello. For 228 instance, if the malware uses evasion techniques like ClientHello 229 randomization, the observable list of cipher suites and extensions 230 offered by the malware agent in the ClientHello message will not 231 match the list of cipher suites and extensions offered by the 232 legitimate client in the ClientHello message, and the middle-box can 233 block malicious flows without acting as a (D)TLS 1.3 proxy. 235 4.1. Full (D)TLS 1.3 handshake inspection 237 To obtain more visibility into negotiated TLS 1.3 parameters, a 238 middlebox needs to act as a (D)TLS 1.3 proxy. The middlebox MUST 239 follow the behaviour explained in Section 9.3 of [RFC8446] to act as 240 a compliant (D)TLS 1.3 proxy. 242 To function as a (D)TLS proxy the middlebox creates a signed 243 certificate using itself as a certificate authority. That 244 certificate authority has to be trusted by the (D)TLS client. The 245 following steps explain the mechanism to automatically bootstrap IoT 246 devices with the middlebox's CA certificate. 248 Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed in 249 [I-D.ietf-anima-bootstrapping-keyinfra] provides a solution for 250 secure automated bootstrap of devices. BRSKI specifies means to 251 provision credentials on devices to be used to operationally access 252 networks. In addition, BRSKI provides an automated mechanism for the 253 bootstrap distribution of CA certificates from the Enrollment over 254 Secure Transport (EST) [RFC7030] server. The IoT device can use 255 BRSKI to automatically bootstrap the IoT device using the IoT 256 manufacturer provisioned X.509 certificate, in combination with a 257 registrar provided by the local network and IoT device manufacturer's 258 authorizing service (MASA). 260 1. The IoT device authenticates to the local network using the IoT 261 manufacturer provisioned X.509 certificate. The IoT device can 262 request and get a voucher from the MASA service via the 263 registrar. The voucher is signed by the MASA service and 264 includes the local network's CA public key. 266 2. The IoT device validates the signed voucher using the 267 manufacturer installed trust anchor associated with the MASA, 268 stores the CA's public key and validates the provisional TLS 269 connection to the registrar. 271 3. The IoT device requests the full EST distribution of current CA 272 certificates (Section 5.9.1 in 273 [I-D.ietf-anima-bootstrapping-keyinfra]) from the registrar 274 operating as a BRSKI-EST server. The IoT device stores the CA 275 certificates as Explicit Trust Anchor database entries. The IoT 276 device uses the Explicit Trust Anchor database to validate the 277 server certificate. 279 4. The middle-box uses the "supported_versions" TLS extension 280 (defined in TLS 1.3 to negotiate the supported TLS versions 281 between client and server) to determine the TLS version. During 282 the (D)TLS handshake, If (D)TLS version 1.3 is used, the middle- 283 box ((D)TLS proxy) modifies the certificate provided by the 284 server and signs it with the private key from the local CA 285 certificate. The middle-box has visibility into further 286 exchanges between the IoT device and server which enables it to 287 inspect the (D)TLS 1.3 handshake, enforce the MUD (D)TLS profile 288 and can inspect subsequent network traffic. 290 5. The IoT device uses the Explicit Trust Anchor database to 291 validate the server certificate. 293 4.2. Encrypted SNI 295 To increase privacy, encrypted SNI (ESNI, 296 [I-D.ietf-tls-sni-encryption]) prevents passive observation of the 297 TLS Server Name Indication which improves privacy. To effectively 298 provide that privacy protection, SNI encryption needs to be used in 299 conjunction with DNS encryption (e.g., DNS-over-(D)TLS or DNS-over- 300 HTTPS). An in-line network device (e.g., firewall) passively 301 inspecting an encrypted SNI (D)TLS handshake cannot observe the 302 encrypted SNI nor observe the encrypted DNS traffic. If an IoT 303 device is pre-configured to use public DNS-over-(D)TLS or DNS-over- 304 HTTPS servers, the middle-box needs to act as a DNS-over-TLS or DNS- 305 over-HTTPS proxy and replace the esni_keys in the ESNI record with 306 the middle box's esni_keys. Instead of an unappealing DNS-over-TLS 307 or DNS-over-HTTPS proxy, the IoT device can be bootstrapped to 308 discover and authenticate DNS-over-(D)TLS and DNS-over-HTTPS servers 309 provided by a local network using 310 [I-D.reddy-dprive-bootstrap-dns-server] and [I-D.sah-resinfo-doh]. 311 The local DNS-over-(D)TLS and DNS-over-HTTPS server replaces the 312 sni_keys in the ESNI record with the middle box's esni_keys. 314 Note that if an IoT device is pre-configured to use public DNS- 315 over-(D)TLS or DNS-over-HTTPS servers, the MUD policy enforcement 316 point is moved to that public server, which cannot enforce the MUD 317 policy based on domain names (Section 8 of [RFC8520]). Thus the use 318 of a public DNS-over-(D)TLS or DNS-over-HTTPS server is incompatible 319 with MUD in general. A local DNS server is necessary to allow MUD 320 policy enforcement on the local network. 322 5. (D)TLS profile YANG module 324 This document specifies a YANG module for representing (D)TLS 325 profile. The (D)TLS profile YANG module provides a method for 326 firewall to observe the (D)TLS profile parameters in the (D)TLS 327 handshake to permit intended use and to block malicious behavior. 328 This module uses the common YANG types defined in [RFC6991] , rules 329 defined in [RFC8519] and cryptographic types defined in 330 [I-D.ietf-netconf-crypto-types]. 332 The (D)TLS profiles and the parameters in each (D)TLS profile include 333 the following: 335 o Profile name 337 o (D)TLS version in ClientHello.legacy_version 338 o (D)TLS versions supported by the IoT device. As a reminder, 339 "supported_versions" extension defined in (D)TLS 1.3 is used by 340 the client to indicate which versions of (D)TLS it supports and a 341 client is considered to be attempting to negotiate (D)TLS 1.3 if 342 the ClientHello contains a "supported_versions" extension with 343 0x0304 contained in its body. 345 o If GREASE [I-D.ietf-tls-grease] (Generate Random Extensions And 346 Sustain Extensibility) values are offered by the client or not. 348 o List of supported symmetric encryption algorithms 350 o List of supported compression methods 352 o List of supported extension types 354 o List of trust anchor certificates used by the IoT device. If the 355 server certificate is signed by one of the trust anchors, the 356 middle-box continues with the connection as normal. Otherwise, 357 the middle-box will react as if the server certificate validation 358 has failed and takes appropriate action (e.g, block the (D)TLS 359 session). Note that server certificate is encrypted in (D)TLS 1.3 360 and the middle-box without acting as (D)TLS proxy cannot validate 361 the server certificate. 363 o List of SPKI pin set pre-configured on the client to validate 364 self-signed server certificates or raw public keys. A SPKI pin 365 set is a cryptographic digest to "pin" public key information in a 366 manner similar to HTTP Public Key Pinning (HPKP) [RFC7469]. If 367 SPKI pin set is present in the (D)TLS profile of a IoT device and 368 the server certificate does not pass the PKIX certification path 369 validation, the middle-box computes the SPKI Fingerprint for the 370 public key found in the server's certificate (or in the raw public 371 key, if the server provides that instead). If a computed 372 fingerprint exactly matches one of the SPKI pin sets in the (D)TLS 373 profile, the middle-box continues with the connection as normal. 374 Otherwise, the middle-box will act on the SPKI validation failure 375 and takes appropriate action. 377 o Cryptographic hash algorithm used to generate the SPKI pinsets 379 o List of pre-shared key exchange modes 381 o List of named groups (DHE or ECDHE) supported by the client 383 o List signature algorithms the client can validate in X.509 server 384 certificates 386 o List of client key exchange algorithms and the client public key 387 lengths in versions prior to (D)TLS 1.3 389 The (D)TLS profile parameters MUST NOT include the GREASE values for 390 extension types, named groups, signature algorithms, (D)TLS versions, 391 pre-shared key exchange modes and cipher suites. Note that the 392 GREASE values are random and peers will ignore these values and 393 interoperate. 395 If the (D)TLS profile parameters are not observed in a (D)TLS session 396 from the IoT device, the default behaviour is to block the (D)TLS 397 session. 399 Note: The TLS and DTLS IANA registries are available from 400 . 402 5.1. Tree Structure 404 This document augments the "ietf-mud" MUD YANG module defined in 405 [RFC8520] for signaling the IoT device (D)TLS profile. This document 406 defines the YANG module "reddy-opsawg-mud-tls-profile", which has the 407 following tree structure: 409 module: reddy-opsawg-mud-tls-profile 410 augment /mud:mud/mud:from-device-policy: 411 +--rw client-profile 412 +--rw tls-profiles* [profile-name] 413 +--rw profile-name string 414 +--rw protocol-version? uint16 415 +--rw supported_versions* uint16 416 +--rw grease_extension? boolean 417 +--rw encryption-algorithms* encryption-algorithm 418 +--rw compression-methods* compression-method 419 +--rw extension-types* extension-type 420 +--rw acceptlist-ta-certs* ct:trust-anchor-cert-cms 421 +--rw SPKI-pin-sets* SPKI-pin-set 422 +--rw SPKI-hash-algorithm ct:hash-algorithm-t 423 +--rw psk-key-exchange-modes* psk-key-exchange-mode 424 +--rw supported-groups* supported-group 425 +--rw signature-algorithms* signature-algorithm 426 +--rw client-public-keys 427 | +--rw key-exchange-algorithms* key-exchange-algorithm 428 | +--rw client-public-key-lengths* client-public-key-length 429 +--rw actions 430 +--rw forwarding identityref 432 5.2. YANG Module 434 module reddy-opsawg-mud-tls-profile { 435 yang-version 1.1; 436 namespace "urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile"; 437 prefix mud-tls-profile; 439 import ietf-crypto-types { 440 prefix ct; 441 reference "draft-ietf-netconf-crypto-types-01: 442 Common YANG Data Types for Cryptography"; 443 } 445 import ietf-inet-types { 446 prefix inet; 447 reference "Section 4 of RFC 6991"; 448 } 450 import ietf-mud { 451 prefix mud; 452 reference "RFC 8520"; 453 } 455 import ietf-access-control-list { 456 prefix ietf-acl; 457 reference 458 "RFC 8519: YANG Data Model for Network Access 459 Control Lists (ACLs)"; 460 } 462 organization 463 "IETF Operations and Management Area Working Group Working Group"; 464 contact 465 "Editor: Konda, Tirumaleswar Reddy 466 "; 468 description 469 "This module contains YANG definition for the IoT device 470 (D)TLS profile. 472 Copyright (c) 2019 IETF Trust and the persons identified as 473 authors of the code. All rights reserved. 475 Redistribution and use in source and binary forms, with or 476 without modification, is permitted pursuant to, and subject 477 to the license terms contained in, the Simplified BSD License 478 set forth in Section 4.c of the IETF Trust's Legal Provisions 479 Relating to IETF Documents 480 (http://trustee.ietf.org/license-info). 482 This version of this YANG module is part of RFC XXXX; see 483 the RFC itself for full legal notices."; 485 revision 2019-06-12 { 486 description 487 "Initial revision"; 488 } 490 typedef compression-method { 491 type uint8; 492 description "Compression method"; 493 } 495 typedef extension-type { 496 type uint16; 497 description "Extension type"; 498 } 500 typedef encryption-algorithm { 501 type uint16; 502 description "Encryption algorithm"; 503 } 505 typedef supported-group { 506 type uint16; 507 description "Named group (DHE or ECDHE)"; 508 } 510 typedef SPKI-pin-set { 511 type binary; 512 description "Subject Public Key Info pin set"; 513 } 515 typedef signature-algorithm { 516 type uint16; 517 description "Signature algorithm"; 518 } 520 typedef key-exchange-algorithm { 521 type uint8; 522 description "key exchange algorithm"; 523 } 525 typedef psk-key-exchange-mode { 526 type uint8; 527 description "pre-shared key exchange mode"; 528 } 530 typedef client-public-key-length { 531 type uint8; 532 description "client public key length"; 533 } 535 augment "/mud:mud/mud:from-device-policy" { 536 container client-profile { 537 list tls-profiles { 538 key "profile-name"; 539 description 540 "A list of (D)TLS version profiles supported by the client."; 541 leaf profile-name { 542 type string { 543 length "1..64"; 544 } 545 description 546 "The name of (D)TLS profile; space and special 547 characters are not allowed."; 548 } 549 leaf protocol-version { 550 type uint16; 551 description "(D)TLS version in ClientHello.legacy_version"; 552 } 553 leaf-list supported_versions { 554 type uint16; 555 description 556 "TLS versions supported by the client indicated 557 in the supported_versions extension in (D)TLS 1.3."; 558 } 559 leaf Grease_extension { 560 type boolean; 561 description 562 "If set to 'true', Grease extension values are offered by 563 the client."; 564 } 565 leaf-list encryption-algorithms { 566 type encryption-algorithm; 567 description "Encryption algorithms"; 568 } 569 leaf-list compression-methods { 570 type compression-method; 571 description "Compression methods"; 572 } 573 leaf-list extension-types { 574 type extension-type; 575 description "Extension Types"; 576 } 577 leaf-list acceptlist-ta-certs { 578 type ct:trust-anchor-cert-cms; 579 description 580 "A list of trust anchor certificates used by the client."; 581 } 582 leaf-list SPKI-pin-sets { 583 type SPKI-pin-set; 584 description 585 "A list of SPKI pin sets pre-configured on the client 586 to validate self-signed server certificate or 587 raw public key."; 588 } 589 leaf SPKI-hash-algorithm { 590 type ct:hash-algorithm-t; 591 description 592 "cryptographic hash algorithm used to generate the 593 SPKI pinset."; 594 } 595 leaf-list psk-key-exchange-modes { 596 type psk-key-exchange-mode; 597 description 598 "pre-shared key exchange modes"; 599 } 600 leaf-list supported-groups { 601 type supported-group; 602 description 603 "A list of named groups supported by the client."; 604 } 605 leaf-list signature-algorithms { 606 type signature-algorithm; 607 description 608 "A list signature algorithms the client can validate 609 in X.509 certificates."; 610 } 611 container client-public-keys { 612 leaf-list key-exchange-algorithms { 613 type key-exchange-algorithm; 614 description 615 "Key exchange algorithms supported by the client"; 616 } 617 leaf-list client-public-key-lengths { 618 type client-public-key-length; 619 description 620 "client public key lengths"; 621 } 622 } 623 container actions { 624 description 625 "Definitions of action for this profile."; 626 leaf forwarding { 627 type identityref { 628 base ietf-acl:forwarding-action; 629 } 630 mandatory true; 631 description 632 "Specifies the forwarding action for the (D)TLS profile."; 633 reference 634 "RFC 8519: YANG Data Model for Network Access 635 Control Lists (ACLs)"; 636 } 637 } 638 } 639 } 640 } 641 } 643 6. MUD File Example 645 This example below contains (D)TLS profile parameters for a IoT 646 device. JSON encoding of YANG modelled data [RFC7951] is used to 647 illustrate the example. 649 { 650 "ietf-mud:mud": { 651 "mud-version": 1, 652 "mud-url": "https://example.com/IoTDevice", 653 "last-update": "2019-18-06T03:56:40.105+10:00", 654 "cache-validity": 100, 655 "is-supported": true, 656 "systeminfo": "IoT device name", 657 "reddy-opsawg-mud-tls-profile:from-device-policy": { 658 "client-profile": { 659 "tls-version-profile" : [ 660 { 661 "protocol-version" : 771, 662 "supported_versions_ext" : "FALSE", 663 "encryption-algorithms" : [31354, 4865, 4866, 4867], 664 "extension-types" : [10], 665 "supported-groups" : [29], 666 "actions": { 667 "forwarding": "accept" 668 } 669 } 670 ] 671 } 672 } 673 } 674 } 676 7. Security Considerations 678 Security considerations in [RFC8520] need to be taken into 679 consideration. Although it is challenging for a malware to mimic the 680 TLS behavior of various IoT device types and IoT device models from 681 several manufacturers, malicious agents have a very low probabilty of 682 using the same (D)TLS profile parameters as legitimate agents on the 683 IoT device to evade detection. Network security services should also 684 rely on contextual network data to detect false negatives. In order 685 to detect such malicious flows, anomaly detection (deep learning 686 techniques on network data) can be used to detect malicious agents 687 using the same (D)TLS profile parameters as legitimate agent on the 688 IoT device. In anomaly detection, the main idea is to maintain 689 rigorous learning of "normal" behavior and where an "anomaly" (or an 690 attack) is identified and categorized based on the knowledge about 691 the normal behavior and a deviation from this normal behavior. 693 8. IANA Considerations 695 This document requests IANA to register the following URIs in the 696 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 698 URI: urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile 699 Registrant Contact: The IESG. 700 XML: N/A; the requested URI is an XML namespace. 702 9. Acknowledgments 704 Thanks to Flemming Andreasen, Shashank Jain, and Harsha Joshi for the 705 discussion and comments. 707 10. References 709 10.1. Normative References 711 [I-D.ietf-netconf-crypto-types] 712 Watsen, K. and H. Wang, "Common YANG Data Types for 713 Cryptography", draft-ietf-netconf-crypto-types-13 (work in 714 progress), November 2019. 716 [I-D.ietf-tls-dtls13] 717 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 718 Datagram Transport Layer Security (DTLS) Protocol Version 719 1.3", draft-ietf-tls-dtls13-34 (work in progress), 720 November 2019. 722 [I-D.ietf-tls-grease] 723 Benjamin, D., "Applying GREASE to TLS Extensibility", 724 draft-ietf-tls-grease-04 (work in progress), August 2019. 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, 728 DOI 10.17487/RFC2119, March 1997, 729 . 731 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 732 DOI 10.17487/RFC3688, January 2004, 733 . 735 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 736 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 737 January 2012, . 739 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 740 RFC 6991, DOI 10.17487/RFC6991, July 2013, 741 . 743 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 744 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 745 May 2017, . 747 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 748 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 749 . 751 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 752 "YANG Data Model for Network Access Control Lists (ACLs)", 753 RFC 8519, DOI 10.17487/RFC8519, March 2019, 754 . 756 10.2. Informative References 758 [I-D.ietf-anima-bootstrapping-keyinfra] 759 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 760 and K. Watsen, "Bootstrapping Remote Secure Key 761 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 762 keyinfra-34 (work in progress), January 2020. 764 [I-D.ietf-tls-sni-encryption] 765 Huitema, C. and E. Rescorla, "Issues and Requirements for 766 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-09 767 (work in progress), October 2019. 769 [I-D.reddy-dprive-bootstrap-dns-server] 770 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 771 "A Bootstrapping Procedure to Discover and Authenticate 772 DNS-over-(D)TLS and DNS-over-HTTPS Servers", draft-reddy- 773 dprive-bootstrap-dns-server-06 (work in progress), January 774 2020. 776 [I-D.sah-resinfo-doh] 777 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 778 Information: "doh"", draft-sah-resinfo-doh-00 (work in 779 progress), May 2019. 781 [malware] Anderson, B., Paul, S., and D. McGrew, "Deciphering 782 Malware's use of TLS (without Decryption)", July 2016, 783 . 785 [malware-tls] 786 Anderson, B. and D. McGrew, "Deciphering Malware's use of 787 TLS (without Decryption)", October 2019, 788 . 790 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 791 "Enrollment over Secure Transport", RFC 7030, 792 DOI 10.17487/RFC7030, October 2013, 793 . 795 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 796 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 797 2015, . 799 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 800 RFC 7951, DOI 10.17487/RFC7951, August 2016, 801 . 803 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 804 Description Specification", RFC 8520, 805 DOI 10.17487/RFC8520, March 2019, 806 . 808 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 809 Things (IoT) Security: State of the Art and Challenges", 810 RFC 8576, DOI 10.17487/RFC8576, April 2019, 811 . 813 Authors' Addresses 815 Tirumaleswar Reddy 816 McAfee, Inc. 817 Embassy Golf Link Business Park 818 Bangalore, Karnataka 560071 819 India 821 Email: kondtir@gmail.com 823 Dan Wing 824 Citrix Systems, Inc. 825 4988 Great America Pkwy 826 Santa Clara, CA 95054 827 USA 829 Email: danwing@gmail.com 830 Blake Anderson 831 Cisco Systems, Inc. 832 170 West Tasman Dr 833 San Jose, CA 95134 834 USA 836 Email: blake.anderson@cisco.com