idnits 2.17.1 draft-ietf-opsawg-mud-tls-06.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 33 instances of too long lines in the document, the longest one being 30 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 424 has weird spacing: '... cipher ian...' -- The document date (5 March 2022) is 780 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: '10' on line 1074 -- Looks like a reference, but probably isn't: '11' on line 1074 -- Looks like a reference, but probably isn't: '13' on line 1074 -- Looks like a reference, but probably isn't: '16' on line 1074 -- Looks like a reference, but probably isn't: '24' on line 1074 -- Looks like a reference, but probably isn't: '29' on line 1075 == Missing Reference: 'RFCXXXX' is mentioned on line 1246, but not defined == Missing Reference: 'RFC5246' is mentioned on line 1263, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'RFC6346' is mentioned on line 1280, but not defined == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-21 ** 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 (-13) exists of draft-ietf-opsawg-mud-iot-dns-considerations-03 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-14 == Outdated reference: A later version (-09) exists of draft-ietf-uta-tls13-iot-profile-03 -- 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: 4 errors (**), 0 flaws (~~), 10 warnings (==), 10 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: 6 September 2022 Citrix 6 B. Anderson 7 Cisco 8 5 March 2022 10 Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices 11 draft-ietf-opsawg-mud-tls-06 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 6 September 2022. 38 Copyright Notice 40 Copyright (c) 2022 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Overview of MUD (D)TLS profiles for IoT devices . . . . . . . 5 57 4. (D)TLS 1.3 Handshake . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Full (D)TLS 1.3 Handshake Inspection . . . . . . . . . . 7 59 4.2. Encrypted DNS . . . . . . . . . . . . . . . . . . . . . . 7 60 5. (D)TLS Profile of a IoT device . . . . . . . . . . . . . . . 8 61 5.1. Tree Structure of the (D)TLS profile Extension to the ACL 62 YANG Model . . . . . . . . . . . . . . . . . . . . . . . 10 63 5.2. The (D)TLS profile Extension to the ACL YANG Model . . . 10 64 5.3. IANA (D)TLS profile YANG Module . . . . . . . . . . . . . 15 65 5.4. MUD (D)TLS Profile Extension . . . . . . . . . . . . . . 20 66 6. Processing of the MUD (D)TLS Profile . . . . . . . . . . . . 21 67 7. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 22 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 69 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 71 10.1. (D)TLS Profile YANG Modules . . . . . . . . . . . . . . 25 72 10.2. ACL TLS Version registry . . . . . . . . . . . . . . . . 27 73 10.3. ACL DTLS version registry . . . . . . . . . . . . . . . 28 74 10.4. ACL (D)TLS Parameters registry . . . . . . . . . . . . . 28 75 10.5. MUD Extensions registry . . . . . . . . . . . . . . . . 29 76 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 78 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 79 12.2. Informative References . . . . . . . . . . . . . . . . . 31 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 82 1. Introduction 84 Encryption is necessary to enhance the privacy of end users using IoT 85 devices. TLS [RFC8446] and DTLS [I-D.ietf-tls-dtls13] are the 86 dominant protocols (counting all (D)TLS versions) providing 87 encryption for IoT device traffic. Unfortunately, in conjunction 88 with IoT applications' rise of encryption, malware authors are also 89 using encryption which thwarts network-based analysis such as deep 90 packet inspection (DPI). Other mechanisms are thus needed to help 91 detecting malware running on an IoT device. 93 Malware frequently uses proprietary libraries for its activities, and 94 those libraries are reused much like any other software engineering 95 project. [malware] indicates that there are observable differences in 96 how malware uses encryption compared with how non-malware uses 97 encryption. There are several interesting findings specific to 98 (D)TLS which were found common to malware: 100 * Older and weaker cryptographic parameters (e.g., 101 TLS_RSA_WITH_RC4_128_SHA). 103 * TLS server name indication (SNI) extension [RFC6066] and server 104 certificates are composed of subjects with characteristics of a 105 domain generation algorithm (DGA) (e.g., 'www.33mhwt2j.net'). 107 * Higher use of self-signed certificates compared with typical 108 legitimate software. 110 * Discrepancies in the SNI TLS extension and the DNS names in the 111 SubjectAltName (SAN) X.509 extension in the server certificate 112 message. 114 * Discrepancies in the key exchange algorithm and the client public 115 key length in comparison with legitimate flows. As a reminder, 116 the Client Key Exchange message has been removed from TLS 1.3. 118 * Lower diversity in TLS client advertised extensions compared to 119 legitimate clients. 121 * Using privacy enhancing technologies like Tor, Psiphon, Ultrasurf 122 (see [malware-tls]), and evasion techniques such as ClientHello 123 randomization. 125 * Using DNS-over-HTTPS (DoH) [RFC8484] to avoid detection by malware 126 DNS filtering services [malware-doh]. Specifically, malware may 127 not use the DoH server provided by the local network. 129 If observable (D)TLS profile parameters are used, the following 130 functions are possible which have a positive impact on the local 131 network security: 133 * Permit intended DTLS or TLS use and block malicious DTLS or TLS 134 use. This is superior to the layers 3 and 4 ACLs of Manufacturer 135 Usage Description Specification (MUD) [RFC8520] which are not 136 suitable for broad communication patterns. 138 * Ensure TLS certificates are valid. Several TLS deployments have 139 been vulnerable to active Man-In-The-Middle (MITM) attacks because 140 of the lack of certificate validation or vulnerability in the 141 certificate validation function (see [cryto-vulnerability]). By 142 observing (D)TLS profile parameters, a network element can detect 143 when the TLS SNI mismatches the SubjectAltName and when the 144 server's certificate is invalid. In TLS 1.2, the ClientHello, 145 ServerHello and Certificate messages are all sent in clear-text. 146 This check is not possible with TLS 1.3, which encrypts the 147 Certificate message thereby hiding the server identity from any 148 intermediary. In TLS 1.3, the server certificate validation 149 functions should be executed within an on-path TLS proxy, if such 150 a proxy exists. 152 * Support new communication patterns. An IoT device can learn a new 153 capability, and the new capability can change the way the IoT 154 device communicates with other devices located in the local 155 network and Internet. There would be an inaccurate policy if an 156 IoT device rapidly changes the IP addresses and domain names it 157 communicates with while the MUD ACLs were slower to update (see 158 [clear-as-mud]). In such a case, observable (D)TLS profile 159 parameters can be used to permit intended use and to block 160 malicious behavior from the IoT device. 162 The YANG module specified in Section 5 of this document is an 163 extension of YANG Data Model for Network Access Control Lists (ACLs) 164 [RFC8519] to enhance MUD [RFC8520] to model observable (D)TLS profile 165 parameters. Using these (D)TLS profile parameters, an active MUD- 166 enforcing network security service (e.g., firewall) can identify MUD 167 non-compliant (D)TLS behavior indicating outdated cryptography or 168 malware. This detection can prevent malware downloads, block access 169 to malicious domains, enforce use of strong ciphers, stop data 170 exfiltration, etc. In addition, organizations may have policies 171 around acceptable ciphers and certificates for the websites the IoT 172 devices connect to. Examples include no use of old and less secure 173 versions of TLS, no use of self-signed certificates, deny-list or 174 accept-list of Certificate Authorities, valid certificate expiration 175 time, etc. These policies can be enforced by observing the (D)TLS 176 profile parameters. Network security services can use the IoT 177 device's (D)TLS profile parameters to identify legitimate flows by 178 observing (D)TLS sessions, and can make inferences to permit 179 legitimate flows and to block malicious or insecure flows. The 180 proposed technique is also suitable in deployments where decryption 181 techniques are not ideal due to privacy concerns, non-cooperating 182 end-points, and expense. 184 2. Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 188 "OPTIONAL" in this document are to be interpreted as described in BCP 189 14 [RFC2119][RFC8174] when, and only when, they appear in all 190 capitals, as shown here. 192 "(D)TLS" is used for statements that apply to both Transport Layer 193 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 194 Specific terms are used for any statement that applies to either 195 protocol alone. 197 'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS. 199 3. Overview of MUD (D)TLS profiles for IoT devices 201 In Enterprise networks, protection and detection are typically done 202 both on end hosts and in the network. Host security agents have deep 203 visibility on the devices where they are installed, whereas the 204 network has broader visibility. Installing host security agents may 205 not be a viable option on IoT devices, and network-based security is 206 an efficient means to protect such IoT devices. If the IoT device 207 supports a MUD (D)TLS profile, the (D)TLS profile parameters of the 208 IoT device can be used by a middlebox to detect and block malware 209 communication, while at the same time preserving the privacy of 210 legitimate uses of encryption. The middlebox need not proxy (D)TLS 211 but can passively observe the parameters of (D)TLS handshakes from 212 IoT devices and gain visibility into TLS 1.2 parameters and partial 213 visibility into TLS 1.3 parameters. 215 Malicious agents can try to use the (D)TLS profile parameters of 216 legitimate agents to evade detection, but it becomes a challenge to 217 mimic the behavior of various IoT device types and IoT device models 218 from several manufacturers. In other words, malware developers will 219 have to develop malicious agents per IoT device type, manufacturer 220 and model, infect the device with the tailored malware agent and will 221 have keep up with updates to the device's (D)TLS profile parameters 222 over time. Furthermore, the malware's command and control server 223 certificates need to be signed by the same certifying authorities 224 trusted by the IoT devices. Typically, IoT devices have an 225 infrastructure that supports a rapid deployment of updates, and 226 malware agents will have a near-impossible task of similarly 227 deploying updates and continuing to mimic the TLS behavior of the IoT 228 device it has infected. However, if the IoT device has reached end- 229 of-life and the IoT manufacturer will not issue a firmware or 230 software update to the Thing or will not update the MUD file, the 231 "is-supported" attribute defined in Section 3.6 of [RFC8520] can be 232 used by the MUD manager to identify the IoT manufacturer no longer 233 supports the device. 235 The end-of-life of a device does not necessarily mean that it is 236 defective; rather, it denotes a need to replace and upgrade the 237 network to next-generation devices for additional functionality. The 238 network security service will have to rely on other techniques 239 discussed in Section 8 to identify malicious connections until the 240 device is replaced. 242 Compromised IoT devices are typically used for launching DDoS attacks 243 (Section 3 of [RFC8576]). For example, DDoS attacks like Slowloris 244 and Transport Layer Security (TLS) re-negotiation can be blocked if 245 the victim's server certificate is not be signed by the same 246 certifying authorities trusted by the IoT device. 248 4. (D)TLS 1.3 Handshake 250 In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since 251 all (D)TLS handshake messages excluding the ClientHello message are 252 encrypted. (D)TLS 1.3 has introduced new extensions in the handshake 253 record layers called Encrypted Extensions. Using these extensions 254 handshake messages will be encrypted and network security services 255 (such as a firewall) are incapable to decipher the handshake, and 256 thus cannot view the server certificate. However, the ClientHello 257 and ServerHello still have some fields visible, such as the list of 258 supported versions, named groups, cipher suites, signature algorithms 259 and extensions in ClientHello, and chosen cipher in the ServerHello. 260 For instance, if the malware uses evasion techniques like ClientHello 261 randomization, the observable list of cipher suites and extensions 262 offered by the malware agent in the ClientHello message will not 263 match the list of cipher suites and extensions offered by the 264 legitimate client in the ClientHello message, and the middlebox can 265 block malicious flows without acting as a (D)TLS 1.3 proxy. 267 4.1. Full (D)TLS 1.3 Handshake Inspection 269 To obtain more visibility into negotiated TLS 1.3 parameters, a 270 middlebox can act as a (D)TLS 1.3 proxy. A middlebox can act as a 271 (D)TLS proxy for the IoT devices owned and managed by the IT team in 272 the Enterprise network and the (D)TLS proxy must meet the security 273 and privacy requirements of the organization. In other words, the 274 scope of middlebox acting as a (D)TLS proxy is restricted to 275 Enterprise network owning and managing the IoT devices. The 276 middlebox would have to follow the behaviour detailed in Section 9.3 277 of [RFC8446] to act as a compliant (D)TLS 1.3 proxy. 279 To further increase privacy, Encrypted Client Hello (ECH) extension 280 [I-D.ietf-tls-esni] prevents passive observation of the TLS Server 281 Name Indication extension and other potentially sensitive fields, 282 such as the ALPN [RFC7301]. To effectively provide that privacy 283 protection, ECH extension needs to be used in conjunction with DNSSEC 284 or DNS encryption (e.g., DoH). A middlebox (e.g., firewall) 285 passively inspecting ECH extension cannot observe the encrypted SNI 286 nor observe the encrypted DNS traffic. The middlebox would have to 287 follow the behaviour detailed in [I-D.ietf-tls-esni] to disable ECH 288 or fake ECH records in the DNS response so that the client encrypts 289 data to the middlebox or strips the ECH record from the DNS response. 290 However, if the client performs full DNSSEC validation locally 291 [RFC6698], it can detect forged DNS responses. 293 4.2. Encrypted DNS 295 A common usage pattern for certain type of IoT devices (e.g., light 296 bulb) is for it to "call home" to a service that resides on the 297 public Internet, where that service is referenced through a domain 298 name (A or AAAA record). As discussed in Manufacturer Usage 299 Description Specification [RFC8520], because these devices tend to 300 require access to very few sites, all other access should be 301 considered suspect. If an IoT device is pre-configured to use a DNS 302 resolver not signaled by the network, the MUD policy enforcement 303 point is moved to that resolver, which cannot enforce the MUD policy 304 based on domain names (Section 8 of [RFC8520]). If the DNS query is 305 not accessible for inspection, it becomes quite difficult for the 306 infrastructure to suspect anything. Thus the use of a DNS resolver 307 not signaled by the network is incompatible with MUD in general. A 308 network-designated DoH/DoT server is necessary to allow MUD policy 309 enforcement on the local network (Section 6.5 of 310 [I-D.ietf-opsawg-mud-iot-dns-considerations]). 312 5. (D)TLS Profile of a IoT device 314 This document specifies a YANG module for representing (D)TLS 315 profile. The (D)TLS profile YANG module provides a method for 316 network security services to observe the (D)TLS profile parameters in 317 the (D)TLS handshake to permit intended use and to block malicious 318 behavior. This module uses the cryptographic types defined in 319 [I-D.ietf-netconf-crypto-types]. See [RFC7925] for (D)TLS 1.2 and 320 [I-D.ietf-uta-tls13-iot-profile] for DTLS 1.3 recommendations related 321 to IoT devices, and [RFC7525] for additional (D)TLS 1.2 322 recommendations. 324 A companion YANG module is defined to include a collection of (D)TLS 325 parameters and (D)TLS versions maintained by IANA: "iana-tls-profile" 326 (Section 5.3). 328 The (D)TLS parameters in each (D)TLS profile include the following: 330 * Profile name 332 * (D)TLS versions supported by the IoT device. 334 * List of supported cipher suites. For (D)TLS1.2, [RFC7925] 335 recommends AEAD ciphers for IoT devices. 337 * List of supported extension types 339 * List of trust anchor certificates used by the IoT device. If the 340 server certificate is signed by one of the trust anchors, the 341 middlebox continues with the connection as normal. Otherwise, the 342 middlebox will react as if the server certificate validation has 343 failed and takes appropriate action (e.g, block the (D)TLS 344 session). An IoT device can use a private trust anchor to 345 validate a server's certificate (e.g., the private trust anchor 346 can be preloaded at manufacturing time on the IoT device and the 347 IoT device fetches the firmware image from the Firmware server 348 whose certificate is signed by the private CA). This empowers the 349 middlebox to reject TLS sessions to servers that the IoT device 350 does not trust. 352 * List of SPKI pin set pre-configured on the client to validate 353 self-signed server certificates or raw public keys. A SPKI pin 354 set is a cryptographic digest to "pin" public key information in a 355 manner similar to HTTP Public Key Pinning (HPKP) [RFC7469]. If 356 SPKI pin set is present in the (D)TLS profile of a IoT device and 357 the server certificate does not pass the PKIX certification path 358 validation, the middlebox computes the SPKI Fingerprint for the 359 public key found in the server's certificate (or in the raw public 360 key, if the server provides that instead). If a computed 361 fingerprint exactly matches one of the SPKI pin sets in the (D)TLS 362 profile, the middlebox continues with the connection as normal. 363 Otherwise, the middlebox will act on the SPKI validation failure 364 and takes appropriate action. 366 * Cryptographic hash algorithm used to generate the SPKI pinsets 368 * List of pre-shared key exchange modes 370 * List of named groups (DHE or ECDHE) supported by the client 372 * List of signature algorithms the client can validate in X.509 373 server certificates 375 * List of signature algorithms the client is willing to accept for 376 CertificateVerify message (Section 4.2.3 of [RFC8446]). For 377 example, a TLS client implementation can support different sets of 378 algorithms for certificates and in TLS to signal the capabilities 379 in "signature_algorithms_cert" and "signature_algorithms" 380 extensions. 382 * List of supported application protocols (e.g., h3, h2, http/1.1 383 etc.) 385 * List of certificate compression algorithms (defined in 386 [I-D.ietf-tls-certificate-compression]) 388 * List of the distinguished names [X501] of acceptable certificate 389 authorities, represented in DER-encoded format [X690] (defined in 390 Section 4.2.4 of [RFC8446]) 392 GREASE [RFC8701] sends random values on TLS parameters to ensure 393 future extensibility of TLS extensions. Similar random values might 394 be extended to other TLS parameters. Thus, the (D)TLS profile 395 parameters defined in the YANG module by this document MUST NOT 396 include the GREASE values for extension types, named groups, 397 signature algorithms, (D)TLS versions, pre-shared key exchange modes, 398 cipher suites and for any other TLS parameters defined in future 399 RFCs. 401 The (D)TLS profile does not include parameters like compression 402 methods for data compression, [RFC7525] recommends disabling TLS- 403 level compression to prevent compression-related attacks. In TLS 404 1.3, only the "null" compression method is allowed (Section 4.1.2 of 405 [RFC8446]). 407 5.1. Tree Structure of the (D)TLS profile Extension to the ACL YANG 408 Model 410 This document augments the "ietf-acl" ACL YANG module defined in 411 [RFC8519] for signaling the IoT device (D)TLS profile. This document 412 defines the YANG module "ietf-acl-tls", which has the following tree 413 structure: 415 module: ietf-acl-tls 416 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: 417 +--rw client-profile {match-on-tls-dtls}? 418 +--rw client-profile 419 +--rw tls-dtls-profiles* [profile-name] 420 +--rw profile-name string 421 +--rw supported-tls-versions* ianatp:tls-version 422 +--rw supported-dtls-versions* ianatp:dtls-version 423 +--rw cipher-suites* [cipher hash] 424 | +--rw cipher ianatp:cipher-algorithm 425 | +--rw hash ianatp:hash-algorithm 426 +--rw extension-types* 427 | ianatp:extension-type 428 +--rw acceptlist-ta-certs* 429 | ct:trust-anchor-cert-cms 430 +--rw spki 431 | +--rw spki-pin-sets* ianatp:spki-pin-set 432 | +--rw spki-hash-algorithm? iha:hash-algorithm-type 433 +--rw psk-key-exchange-modes* 434 | ianatp:psk-key-exchange-mode 435 | {tls-1-3 or dtls-1-3}? 436 +--rw supported-groups* 437 | ianatp:supported-group 438 +--rw signature-algorithms-cert* 439 | ianatp:signature-algorithm 440 | {tls-1-3 or dtls-1-3}? 441 +--rw signature-algorithms* 442 | ianatp:signature-algorithm 443 +--rw application-protocols* 444 | ianatp:application-protocol 445 +--rw cert-compression-algorithms* 446 | ianatp:cert-compression-algorithm 447 | {tls-1-3 or dtls-1-3}? 448 +--rw certificate-authorities* 449 ianatp:certificate-authority 450 {tls-1-3 or dtls-1-3}? 452 5.2. The (D)TLS profile Extension to the ACL YANG Model 453 file "ietf-acl-tls@2020-10-07.yang" 454 module ietf-acl-tls { 455 yang-version 1.1; 456 namespace "urn:ietf:params:xml:ns:yang:ietf-acl-tls"; 457 prefix ietf-acl-tls; 459 import iana-tls-profile { 460 prefix ianatp; 461 reference 462 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS 463 Profiles for IoT Devices"; 464 } 465 import ietf-crypto-types { 466 prefix ct; 467 reference 468 "RFC CCCC: Common YANG Data Types for Cryptography"; 469 } 470 import iana-hash-algs { 471 prefix iha; 472 reference 473 "RFC IIII: Common YANG Data Types for 474 Hash algorithms"; 475 } 476 import ietf-access-control-list { 477 prefix acl; 478 reference 479 "RFC 8519: YANG Data Model for Network Access 480 Control Lists (ACLs)"; 481 } 483 organization 484 "IETF OPSAWG (Operations and Management Area Working Group)"; 485 contact 486 "WG Web: 487 WG List: opsawg@ietf.org 489 Author: Konda, Tirumaleswar Reddy 490 TirumaleswarReddy_Konda@McAfee.com 491 "; 492 description 493 "This YANG module defines a component that augments the 494 IETF description of an access list to allow (D)TLS profile 495 as matching criteria. 497 Copyright (c) 2020 IETF Trust and the persons identified as 498 authors of the code. All rights reserved. 500 Redistribution and use in source and binary forms, with or 501 without modification, is permitted pursuant to, and subject 502 to the license terms contained in, the Simplified BSD License 503 set forth in Section 4.c of the IETF Trust's Legal Provisions 504 Relating to IETF Documents 505 (http://trustee.ietf.org/license-info). 507 This version of this YANG module is part of RFC XXXX; see 508 the RFC itself for full legal notices."; 510 revision 2020-11-02 { 511 description 512 "Initial revision"; 513 reference 514 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS 515 Profiles for IoT Devices"; 516 } 518 feature tls-1-2 { 519 description 520 "TLS Protocol Version 1.2 is supported."; 521 reference 522 "RFC 5246: The Transport Layer Security (TLS) Protocol 523 Version 1.2"; 524 } 526 feature tls-1-3 { 527 description 528 "TLS Protocol Version 1.3 is supported."; 529 reference 530 "RFC 8446: The Transport Layer Security (TLS) Protocol 531 Version 1.3"; 532 } 534 feature dtls-1-2 { 535 description 536 "DTLS Protocol Version 1.2 is supported."; 537 reference 538 "RFC 6346: Datagram Transport Layer Security 539 Version 1.2"; 540 } 542 feature dtls-1-3 { 543 description 544 "DTLS Protocol Version 1.3 is supported."; 545 reference 546 "draft-ietf-tls-dtls13: Datagram Transport Layer 547 Security 1.3"; 548 } 549 feature match-on-tls-dtls { 550 description 551 "The networking device can support matching on 552 (D)TLS parameters."; 553 } 555 augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" { 556 if-feature "match-on-tls-dtls"; 557 description 558 "(D)TLS specific matches."; 559 container client-profile { 560 description 561 "A grouping for (D)TLS profiles."; 562 container client-profile { 563 description 564 "A grouping for DTLS profiles."; 565 list tls-dtls-profiles { 566 key "profile-name"; 567 description 568 "A list of (D)TLS version profiles supported by 569 the client."; 570 leaf profile-name { 571 type string { 572 length "1..64"; 573 } 574 description 575 "The name of (D)TLS profile; space and special 576 characters are not allowed."; 577 } 578 leaf-list supported-tls-versions { 579 type ianatp:tls-version; 580 description 581 "TLS versions supported by the client."; 582 } 583 leaf-list supported-dtls-versions { 584 type ianatp:dtls-version; 585 description 586 "DTLS versions supported by the client."; 587 } 588 list cipher-suites { 589 key "cipher hash"; 590 leaf cipher { 591 type ianatp:cipher-algorithm; 592 description 593 "AEAD encryption algorithm as defined in RFC5116."; 594 } 595 leaf hash { 596 type ianatp:hash-algorithm; 597 description 598 "Hash algorithm used with HKDF as defined in RFC5869."; 599 } 600 description 601 "A list of Cipher Suites supported by the client."; 602 } 603 leaf-list extension-types { 604 type ianatp:extension-type; 605 description 606 "A list of Extension Types supported by the client."; 607 } 608 leaf-list acceptlist-ta-certs { 609 type ct:trust-anchor-cert-cms; 610 description 611 "A list of trust anchor certificates used by the client."; 612 } 613 container spki { 614 description 615 "A grouping for spki."; 616 leaf-list spki-pin-sets { 617 type ianatp:spki-pin-set; 618 description 619 "A list of SPKI pin sets pre-configured on the client 620 to validate self-signed server certificate or 621 raw public key."; 622 } 623 leaf spki-hash-algorithm { 624 type iha:hash-algorithm-type; 625 description 626 "cryptographic hash algorithm used to generate the 627 SPKI pinset."; 628 } 629 } 630 leaf-list psk-key-exchange-modes { 631 if-feature "tls-1-3 or dtls-1-3"; 632 type ianatp:psk-key-exchange-mode; 633 description 634 "pre-shared key exchange modes."; 635 } 636 leaf-list supported-groups { 637 type ianatp:supported-group; 638 description 639 "A list of named groups supported by the client."; 640 } 641 leaf-list signature-algorithms-cert { 642 if-feature "tls-1-3 or dtls-1-3"; 643 type ianatp:signature-algorithm; 644 description 645 "A list signature algorithms the client can validate 646 in X.509 certificates."; 647 } 648 leaf-list signature-algorithms { 649 type ianatp:signature-algorithm; 650 description 651 "A list signature algorithms the client can validate 652 in the CertificateVerify message."; 653 } 654 leaf-list application-protocols { 655 type ianatp:application-protocol; 656 description 657 "A list application protocols supported by the client."; 658 } 659 leaf-list cert-compression-algorithms { 660 if-feature "tls-1-3 or dtls-1-3"; 661 type ianatp:cert-compression-algorithm; 662 description 663 "A list certificate compression algorithms 664 supported by the client."; 665 } 666 leaf-list certificate-authorities { 667 if-feature "tls-1-3 or dtls-1-3"; 668 type ianatp:certificate-authority; 669 description 670 "A list of the distinguished names of certificate authorities 671 acceptable to the client."; 672 } 673 } 674 } 675 } 676 } 677 } 678 680 5.3. IANA (D)TLS profile YANG Module 682 The TLS and DTLS IANA registries are available from 683 https://www.iana.org/assignments/tls-parameters/tls-parameters.txt 684 and https://www.iana.org/assignments/tls-extensiontype-values/tls- 685 extensiontype-values.txt. 687 The values for all the parameters in the "iana-tls-profile" YANG 688 module are defined in the TLS and DTLS IANA registries excluding the 689 tls-version, dtls-version, spki-pin-set, and certificate-authority 690 parameters. The values of spki-pin-set and certificate-authority 691 parameters will be specific to the IoT device. 693 The TLS and DTLS IANA registries do not maintain (D)TLS version 694 numbers. In (D)TLS 1.2 and below, "legacy_version" field in the 695 ClientHello message is used for version negotiation. However in 696 (D)TLS 1.3, the "supported_versions" extension is used by the client 697 to indicate which versions of (D)TLS it supports. TLS 1.3 698 ClientHello messages are identified as having a "legacy_version" of 699 0x0303 and a "supported_versions" extension present with 0x0304 as 700 the highest version. DTLS 1.3 ClientHello messages are identified as 701 having a "legacy_version" of 0xfefd and a "supported_versions" 702 extension present with 0x0304 as the highest version. 704 In order to ease updating the "iana-tls-profile" YANG module with 705 future (D)TLS versions, new (D)TLS version registries are defined in 706 Section 10.2 and Section 10.3. Whenever a new (D)TLS protocol 707 version is defined, the registry will be updated using expert review; 708 the "iana-tls-profile" YANG module will be automatically updated by 709 IANA. 711 The "iana-tls-profile" YANG module is defined as follows: 713 file "iana-tls-profile@2020-10-07.yang" 714 module iana-tls-profile { 715 yang-version 1.1; 716 namespace "urn:ietf:params:xml:ns:yang:iana-tls-profile"; 717 prefix ianatp; 719 organization 720 "IANA"; 721 contact 722 " Internet Assigned Numbers Authority 724 Postal: ICANN 725 12025 Waterfront Drive, Suite 300 726 Los Angeles, CA 90094-2536 727 United States 729 Tel: +1 310 301 5800 730 E-Mail: iana@iana.org>"; 731 description 732 "This module contains YANG definition for the (D)TLS profile. 734 Copyright (c) 2020 IETF Trust and the persons identified as 735 authors of the code. All rights reserved. 737 Redistribution and use in source and binary forms, with or 738 without modification, is permitted pursuant to, and subject 739 to the license terms contained in, the Simplified BSD License 740 set forth in Section 4.c of the IETF Trust's Legal Provisions 741 Relating to IETF Documents 742 (http://trustee.ietf.org/license-info). 744 This version of this YANG module is part of RFC XXXX; see 745 the RFC itself for full legal notices."; 747 revision 2020-11-02 { 748 description 749 "Initial revision"; 750 reference 751 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS Profiles 752 for IoT Devices"; 753 } 755 typedef extension-type { 756 type uint16; 757 description 758 "Extension type in the TLS ExtensionType Values registry as 759 defined in Section 7 of RFC8447."; 760 } 762 typedef supported-group { 763 type uint16; 764 description 765 "Supported Group in the TLS Supported Groups registry as 766 defined in Section 9 of RFC8447."; 767 } 769 typedef spki-pin-set { 770 type binary; 771 description 772 "Subject Public Key Info pin set as discussed in 773 Section 2.4 of RFC7469."; 774 } 776 typedef signature-algorithm { 777 type uint16; 778 description 779 "Signature algorithm in the TLS SignatureScheme registry as 780 defined in Section 11 of RFC8446."; 781 } 783 typedef psk-key-exchange-mode { 784 type uint8; 785 description 786 "Pre-shared key exchange mode in the TLS PskKeyExchangeMode 787 registry as defined in Section 11 of RFC8446."; 788 } 789 typedef application-protocol { 790 type string; 791 description 792 "Application-Layer Protocol Negotiation (ALPN) Protocol ID 793 registry as defined in Section 6 of RFC7301."; 794 } 796 typedef cert-compression-algorithm { 797 type uint16; 798 description 799 "Certificate compression algorithm in TLS Certificate 800 Compression Algorithm IDs registry as defined in 801 Section 7.3 of ietf-tls-certificate-compression"; 802 } 804 typedef certificate-authority { 805 type string; 806 description 807 "Distinguished Name of Certificate authority as discussed 808 in Section 4.2.4 of RFC8446."; 809 } 811 typedef cipher-algorithm { 812 type uint8; 813 description 814 "AEAD encryption algorithm in TLS Cipher Suites registry 815 as discussed in Section 11 of RFC8446."; 816 } 818 typedef hash-algorithm { 819 type uint8; 820 description 821 "Hash algorithm used with HMAC-based Extract-and-Expand Key 822 Derivation Function (HKDF) in TLS Cipher Suites registry 823 as discussed in Section 11 of RFC8446."; 824 } 826 typedef tls-version { 827 type enumeration { 828 enum tls-1.2 { 829 value 1; 830 description 831 "TLS Protocol Version 1.2. 833 TLS 1.2 ClientHello contains 834 0x0303 in 'legacy_version'."; 835 reference 836 "RFC 5246: The Transport Layer Security (TLS) Protocol 837 Version 1.2"; 838 } 839 enum tls-1.3 { 840 value 2; 841 description 842 "TLS Protocol Version 1.3. 844 TLS 1.3 ClientHello contains a 845 supported_versions extension with 0x0304 846 contained in its body and the ClientHello contains 847 0x0303 in 'legacy_version'."; 848 reference 849 "RFC 8446: The Transport Layer Security (TLS) Protocol 850 Version 1.3"; 851 } 852 } 853 description 854 "Indicates the TLS version."; 855 } 857 typedef dtls-version { 858 type enumeration { 859 enum dtls-1.2 { 860 value 1; 861 description 862 "DTLS Protocol Version 1.2. 864 DTLS 1.2 ClientHello contains 865 0xfefd in 'legacy_version'."; 866 reference 867 "RFC 6346: Datagram Transport Layer Security 1.2"; 868 } 869 enum dtls-1.3 { 870 value 2; 871 description 872 "DTLS Protocol Version 1.3. 874 DTLS 1.3 ClientHello contains a 875 supported_versions extension with 0x0304 876 contained in its body and the ClientHello contains 877 0xfefd in 'legacy_version'."; 878 reference 879 "RFC DDDD: Datagram Transport Layer Security 1.3"; 880 } 881 } 882 description 883 "Indicates the DTLS version."; 884 } 886 } 887 889 5.4. MUD (D)TLS Profile Extension 891 This document augments the "ietf-mud" MUD YANG module to indicate 892 whether the device supports (D)TLS profile. If the "ietf-mud-tls" 893 extension is supported by the device, MUD file is assumed to 894 implement the "match-on-tls-dtls" ACL model feature defined in this 895 specification. Furthermore, only "accept" or "drop" actions SHOULD 896 be included with the (D)TLS profile similar to the actions allowed in 897 Section 2 of [RFC8520]. 899 This document defines the YANG module "ietf-mud-tls", which has the 900 following tree structure: 902 module: ietf-mud-tls 903 augment /ietf-mud:mud: 904 +--rw is-tls-dtls-profile-supported? boolean 906 The model is defined as follows: 908 file "iana-tls-mud@2020-10-20.yang" 909 module ietf-mud-tls { 910 yang-version 1.1; 911 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-tls"; 912 prefix ietf-mud-tls; 914 import ietf-mud { 915 prefix ietf-mud; 916 } 918 organization 919 "IETF OPSAWG (Operations and Management Area Working Group)"; 920 contact 921 "WG Web: 922 WG List: opsawg@ietf.org 924 Author: Konda, Tirumaleswar Reddy 925 TirumaleswarReddy_Konda@McAfee.com 927 "; 928 description 929 "Extension to a MUD module to indicate (D)TLS 930 profile support. 932 Copyright (c) 2020 IETF Trust and the persons identified as 933 authors of the code. All rights reserved. 935 Redistribution and use in source and binary forms, with or 936 without modification, is permitted pursuant to, and subject 937 to the license terms contained in, the Simplified BSD License 938 set forth in Section 4.c of the IETF Trust's Legal Provisions 939 Relating to IETF Documents 940 (http://trustee.ietf.org/license-info). 942 This version of this YANG module is part of RFC XXXX; see 943 the RFC itself for full legal notices."; 945 revision 2020-10-19 { 946 description 947 "Initial revision."; 948 reference 949 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS 950 Profiles for IoT Devices"; 951 } 953 augment "/ietf-mud:mud" { 954 description 955 "This adds a extension for a manufacturer 956 to indicate whether (D)TLS profile is 957 is supported by a device."; 958 leaf is-tls-dtls-profile-supported { 959 type boolean; 960 description 961 "This value will equal 'true' if a device supports 962 (D)TLS profile."; 963 } 964 } 965 } 966 968 6. Processing of the MUD (D)TLS Profile 970 The following text outlines the rules for a network security service 971 (e.g., firewall) to follow to process the MUD (D)TLS Profile: 973 * If the (D)TLS parameter observed in a (D)TLS session is not 974 specified in the MUD (D)TLS profile and the parameter is 975 recognized by the firewall, it can identify unexpected (D)TLS 976 usage, which can indicate the presence of unauthorized software or 977 malware on an endpoint. The firewall can take several actions 978 like block the (D)TLS session or raise an alert to quarantine and 979 remediate the compromised device. For example, if the cipher 980 suite TLS_RSA_WITH_AES_128_CBC_SHA in the ClientHello message is 981 not specified in the MUD (D)TLS profile and the cipher suite is 982 recognized by the firewall, it can identify unexpected TLS usage. 984 * If the (D)TLS parameter observed in a (D)TLS session is not 985 specified in the MUD (D)TLS profile and the (D)TLS parameter is 986 not recognized by the firewall, it can ignore the unrecognized 987 parameter and the correct behavior is not to block the (D)TLS 988 session. The behaviour is functionally equivalent to the 989 compliant TLS middlebox description in Section 9.3 of [RFC8446] to 990 ignore all unrecognized cipher suites, extensions, and other 991 parameters. For example, if the cipher suite 992 TLS_CHACHA20_POLY1305_SHA256 in the ClientHello message is not 993 specified in the MUD (D)TLS profile and the cipher suite is not 994 recognized by the firewall, it can ignore the unrecognized cipher 995 suite. 997 * Deployments update at different rates, so an updated MUD (D)TLS 998 profile may support newer parameters. If the firewall does not 999 recognize the newer parameters, an alert should be triggered to 1000 the firewall vendor and the IoT device owner or administrator. A 1001 firewall must be readily updatable, so that when new parameters in 1002 the MUD (D)TLS profile are discovered that are not recognized by 1003 the firewall, it can be updated quickly. Most importantly, if the 1004 firewall is not readily updatable, its protection efficacy to 1005 identify emerging malware will decrease with time. For example, 1006 if the cipher suite TLS_AES_128_CCM_8_SHA256 specified in the MUD 1007 (D)TLS profile is not recognized by the firewall, an alert will be 1008 triggered. Similarly, if the (D)TLS version specified in the MUD 1009 file is not recognized by the firewall, an alert will be 1010 triggered. 1012 7. MUD File Example 1014 The example below contains (D)TLS profile parameters for a IoT device 1015 used to reach servers listening on port 443 using TCP transport. 1016 JSON encoding of YANG modelled data [RFC7951] is used to illustrate 1017 the example. 1019 { 1020 "ietf-mud:mud": { 1021 "mud-version": 1, 1022 "mud-url": "https://example.com/IoTDevice", 1023 "last-update": "2019-18-06T03:56:40.105+10:00", 1024 "cache-validity": 100, 1025 "extensions": [ 1026 "ietf-mud-tls" 1027 ], 1028 "ietf-mud-tls:is-tls-dtls-profile-supported": "true", 1029 "is-supported": true, 1030 "systeminfo": "IoT device name", 1031 "from-device-policy": { 1032 "access-lists": { 1033 "access-list": [ 1034 { 1035 "name": "mud-7500-profile" 1036 } 1037 ] 1038 } 1039 }, 1040 "ietf-access-control-list:acls": { 1041 "acl": [ 1042 { 1043 "name": "mud-7500-profile", 1044 "type": "ipv6-acl-type", 1045 "aces": { 1046 "ace": [ 1047 { 1048 "name": "cl0-frdev", 1049 "matches": { 1050 "ipv6": { 1051 "protocol": 6 1052 }, 1053 "tcp": { 1054 "ietf-mud:direction-initiated": "from-device", 1055 "destination-port": { 1056 "operator": "eq", 1057 "port": 443 1058 } 1059 }, 1060 "ietf-acl-tls:client-profile" : { 1061 "tls-dtls-profiles" : [ 1062 { 1063 "supported-tls-versions" : ["tls-1.3"], 1064 "cipher-suites" : [ 1065 { 1066 "cipher": 19, 1067 "hash": 1 1068 }, 1069 { 1070 "cipher": 19, 1071 "hash": 2 1072 } 1073 ], 1074 "extension-types" : [10,11,13,16,24], 1075 "supported-groups" : [29] 1076 } 1077 ] 1078 }, 1079 "actions": { 1080 "forwarding": "accept" 1081 } 1082 } 1083 } 1084 ] 1085 } 1086 } 1087 ] 1088 } 1089 } 1090 } 1092 The following illustrates the example scenarios for processing the 1093 above profile: 1095 * If the extension type "encrypt_then_mac" (code point 22) [RFC7366] 1096 in the ClientHello message is recognized by the firewall, it can 1097 identify unexpected TLS usage. 1099 * If the extension type "token_binding" (code point 24) [RFC8472] in 1100 the MUD (D)TLS profile is not recognized by the firewall, it can 1101 ignore the unrecognized extension. Because the extension type 1102 "token_binding" is specified in the profile, an alert will be 1103 triggered to the firewall vendor and the IoT device owner or 1104 administrator to notify the firewall is not up to date. 1106 8. Security Considerations 1108 Security considerations in [RFC8520] need to be taken into 1109 consideration. The middlebox must adhere to the invariants discussed 1110 in Section 9.3 of [RFC8446] to act as a compliant proxy. 1112 Although it is challenging for a malware to mimic the TLS behavior of 1113 various IoT device types and IoT device models from several 1114 manufacturers, malicious agents have a very low probability of using 1115 the same (D)TLS profile parameters as legitimate agents on the IoT 1116 device to evade detection. Network security services should also 1117 rely on contextual network data to detect false negatives. In order 1118 to detect such malicious flows, anomaly detection (deep learning 1119 techniques on network data) can be used to detect malicious agents 1120 using the same (D)TLS profile parameters as legitimate agent on the 1121 IoT device. In anomaly detection, the main idea is to maintain 1122 rigorous learning of "normal" behavior and where an "anomaly" (or an 1123 attack) is identified and categorized based on the knowledge about 1124 the normal behavior and a deviation from this normal behavior. 1126 9. Privacy Considerations 1128 Privacy considerations discussed in Section 16 of [RFC8520] to not 1129 reveal the MUD URL to an attacker need to be taken into 1130 consideration. The MUD URL can be stored in Trusted Execution 1131 Environment (TEE) for secure operation, enhanced data security, and 1132 prevent exposure to unauthorized software. 1134 Full handshake inspection (Section 4.1) requires a TLS proxy device 1135 which needs to decrypt traffic between the IoT device and its 1136 server(s). There is a tradeoff between privacy of the data carried 1137 inside TLS (especially e.g., personally identifiable information and 1138 protected health information) and efficacy of endpoint security. It 1139 is strongly RECOMMENDED to avoid a TLS proxy whenever possible. For 1140 example, an enterprise firewall administrator can configure the 1141 middlebox to bypass TLS proxy functionality or payload inspection for 1142 connections destined to specific well-known services. Alternatively, 1143 a IoT device could be configured to reject all sessions that involve 1144 proxy servers to specific well-known services. In addition, 1145 mechanisms based on object security can be used by IoT devices to 1146 enable end-to-end security and the middlebox will not have any access 1147 to the packet data. For example, Object Security for Constrained 1148 RESTful Environments (OSCORE) [RFC8613] is a proposal that protects 1149 CoAP messages by wrapping them in the COSE format [RFC8152]. 1151 10. IANA Considerations 1153 10.1. (D)TLS Profile YANG Modules 1155 This document requests IANA to register the following URIs in the 1156 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 1158 URI: urn:ietf:params:xml:ns:yang:iana-tls-profile 1159 Registrant Contact: The IESG. 1160 XML: N/A; the requested URI is an XML namespace. 1162 URI: urn:ietf:params:xml:ns:yang:ietf-acl-tls 1163 Registrant Contact: The IESG. 1164 XML: N/A; the requested URI is an XML namespace. 1166 URI: urn:ietf:params:xml:ns:yang:ietf-mud-tls 1167 Registrant Contact: The IESG. 1168 XML: N/A; the requested URI is an XML namespace. 1170 IANA is requested to create an IANA-maintained YANG Module called 1171 "iana-tls-profile", based on the contents of Section 5.3, which will 1172 allow for new (D)TLS parameters and (D)TLS versions to be added to 1173 "client-profile". The registration procedure will be Expert Review, 1174 as defined by [RFC8126]. 1176 This document requests IANA to register the following YANG modules in 1177 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1178 Parameters" registry. 1180 name: iana-tls-profile 1181 namespace: urn:ietf:params:xml:ns:yang:iana-tls-profile 1182 maintained by IANA: Y 1183 prefix: ianatp 1184 reference: RFC XXXX 1186 name: ietf-acl-tls 1187 namespace: urn:ietf:params:xml:ns:yang:ietf-acl-tls 1188 maintained by IANA: N 1189 prefix: ietf-acl-tls 1190 reference: RFC XXXX 1192 name: ietf-mud-tls 1193 namespace: urn:ietf:params:xml:ns:yang:ietf-mud-tls 1194 maintained by IANA: N 1195 prefix: ietf-mud-tls 1196 reference: RFC XXXX 1198 IANA is requested to create an the initial version of the IANA- 1199 maintained YANG Module called "iana-tls-profile", based on the 1200 contents of Section 5.3, which will allow for new (D)TLS parameters 1201 and (D)TLS versions to be added. IANA is requested to add this note: 1203 * tls-version and dtls-version values must not be directly added to 1204 the iana-tls-profile YANG module. They must instead be 1205 respectively added to the "ACL TLS Version Codes", and "ACL DTLS 1206 Version Codes" registries. 1208 * (D)TLS parameters must not be directly added to the iana-tls- 1209 profile YANG module. They must instead be added to the "ACL 1210 (D)TLS Parameters" registry. 1212 When a 'tls-version' or 'dtls-version' value is respectively added to 1213 the "ACL TLS Version Codes" or "ACL DTLS Version Codes" registry, a 1214 new "enum" statement must be added to the iana-tls-profile YANG 1215 module. The following "enum" statement, and substatements thereof, 1216 should be defined: 1218 "enum": Replicates the label from the registry. 1220 "value": Contains the IANA-assigned value corresponding to the 1221 'tls-version' or 'dtls-version'. 1223 "description": Replicates the description from the registry. 1225 "reference": Replicates the reference from the registry and adds 1226 the title of the document. 1228 When a (D)TLS parameter is added to "ACL (D)TLS Parameters" registry, 1229 a new "type" statement must be added to the iana-tls-profile YANG 1230 module. The following "type" statement, and substatements thereof, 1231 should be defined: 1233 "derived type": Replicates the parameter name from the registry. 1235 "built-in type": Contains the built-in YANG type. 1237 "description": Replicates the description from the registry. 1239 When the iana-tls-profile YANG module is updated, a new "revision" 1240 statement must be added in front of the existing revision statements. 1242 IANA is requested to add this note to "ACL TLS Version Codes", "ACL 1243 DTLS Version Codes", and "ACL (D)TLS Parameters" registries: 1245 When this registry is modified, the YANG module iana-tls-profile 1246 must be updated as defined in [RFCXXXX]. 1248 The registration procedure for "ietf-acl-tls" YANG module will be 1249 Specification Required, as defined by [RFC8126]. 1251 10.2. ACL TLS Version registry 1253 IANA is requested to create a new registry titled "ACL TLS Version 1254 Codes". Codes in this registry are used as valid values of 'tls- 1255 version' parameter. Further assignments are to be made through 1256 Expert Review [RFC8126]. 1258 +-------+---------+-----------------+-----------+ 1259 | Value | Label | Description | Reference | 1260 | | | | | 1261 | | | | | 1262 +-------+---------+-----------------+-----------+ 1263 | 1 | tls-1.2 | TLS Version 1.2 | [RFC5246] | 1264 +-------+---------+-----------------+-----------+ 1265 | 2 | tls-1.3 | TLS Version 1.3 | [RFC8446] | 1266 +-------+---------+-----------------+-----------+ 1268 10.3. ACL DTLS version registry 1270 IANA is requested to create a new registry titled "ACL DTLS Version 1271 Codes". Codes in this registry are used as valid values of 'dtls- 1272 version' parameter. Further assignments are to be made through 1273 Expert Review [RFC8126]. 1275 +-------+---------+----------------+-----------------------+ 1276 | Value | Label | Description | Reference | 1277 | | | | | 1278 | | | | | 1279 +-------+---------+----------------+-----------------------+ 1280 | 1 |dtls-1.2 |DTLS Version 1.2| [RFC6346] | 1281 +-------+---------+----------------+-----------------------+ 1282 | 2 |dtls-1.3 |DTLS Version 1.3|[draft-ietf-tls-dtls13]| 1283 +-------+---------+----------------+-----------------------+ 1285 10.4. ACL (D)TLS Parameters registry 1287 IANA is requested to create a new registry titled "ACL (D)TLS 1288 parameters". 1290 The values for all the (D)TLS parameters in the registry are defined 1291 in the TLS and DTLS IANA registries 1292 (https://www.iana.org/assignments/tls-parameters/tls-parameters.txt 1293 and https://www.iana.org/assignments/tls-extensiontype-values/tls- 1294 extensiontype-values.txt) excluding the tls-version, dtls-version, 1295 spki-pin-set and certificate-authority parameters. Further 1296 assignments are to be made through Expert Review [RFC8126]. The 1297 registry is initially populated with the following parameters: 1299 +----------------------------+-------------+--------+---------------------------------------------+ 1300 | Parameter Name | YANG | JSON | | 1301 | | Type | Type | Description | 1302 | | | | | 1303 +----------------------------+-------------+--------+---------------------------------------------+ 1304 | extension-type | uint16 | Number | Extension type | 1305 +----------------------------+-------------+--------+---------------------------------------------+ 1306 | supported-group | uint16 | Number | Supported group | 1307 +----------------------------+-------------+--------+---------------------------------------------+ 1308 | spki-pin-set | binary | String | Subject public key info pin set | 1309 +----------------------------+-------------+--------+---------------------------------------------+ 1310 | signature-algorithm | uint16 | Number | Signature algorithm | 1311 +----------------------------+-------------+--------+---------------------------------------------+ 1312 | psk-key-exchange-mode | uint8 | Number | pre-shared key exchange mode | 1313 +----------------------------+-------------+--------+---------------------------------------------+ 1314 | application-protocol | string | String | Application protocol | 1315 +----------------------------+-------------+--------+---------------------------------------------+ 1316 | cert-compression-algorithm | uint16 | Number | Certificate compression algorithm | 1317 +----------------------------+-------------+--------+---------------------------------------------+ 1318 | certificate-authority | string | String | Distinguished name of Certificate Authority | 1319 +----------------------------+-------------+--------+---------------------------------------------+ 1320 | cipher-algorithm | uint8 | Number | AEAD encryption algorithm | 1321 +----------------------------+-------------+--------+---------------------------------------------+ 1322 | hash-algorithm | uint8 | Number | Hash algorithm | 1323 +----------------------------+-------------+--------+---------------------------------------------+ 1324 | tls-version | enumeration | String | TLS version | 1325 +----------------------------+-------------+--------+---------------------------------------------+ 1326 | dtls-version | enumeration | String | DTLS version | 1327 +----------------------------+-------------+--------+---------------------------------------------+ 1329 10.5. MUD Extensions registry 1331 IANA is requested to create a new MUD Extension Name "ietf-mud-tls" 1332 in the MUD Extensions IANA registry 1333 https://www.iana.org/assignments/mud/mud.xhtml. 1335 11. Acknowledgments 1337 Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson, 1338 Piyush Joshi, Eliot Lear, Harsha Joshi, Qin Wu, Mohamed Boucadair, 1339 Ben Schwartz, Eric Rescorla, Panwei William, Nick Lamb and Nick 1340 Harper for the discussion and comments. 1342 12. References 1344 12.1. Normative References 1346 [I-D.ietf-netconf-crypto-types] 1347 Watsen, K., "YANG Data Types and Groupings for 1348 Cryptography", Work in Progress, Internet-Draft, draft- 1349 ietf-netconf-crypto-types-21, 14 September 2021, 1350 . 1353 [I-D.ietf-tls-certificate-compression] 1354 Ghedini, A. and V. Vasiliev, "TLS Certificate 1355 Compression", Work in Progress, Internet-Draft, draft- 1356 ietf-tls-certificate-compression-10, 6 January 2020, 1357 . 1360 [I-D.ietf-tls-dtls13] 1361 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1362 Datagram Transport Layer Security (DTLS) Protocol Version 1363 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1364 dtls13-43, 30 April 2021, . 1367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1368 Requirement Levels", BCP 14, RFC 2119, 1369 DOI 10.17487/RFC2119, March 1997, 1370 . 1372 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1373 DOI 10.17487/RFC3688, January 2004, 1374 . 1376 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1377 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1378 January 2012, . 1380 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1381 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1382 May 2017, . 1384 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1385 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1386 . 1388 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1389 "YANG Data Model for Network Access Control Lists (ACLs)", 1390 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1391 . 1393 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 1394 Sustain Extensibility (GREASE) to TLS Extensibility", 1395 RFC 8701, DOI 10.17487/RFC8701, January 2020, 1396 . 1398 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 1399 Specification of Basic Encoding Rules (BER), Canonical 1400 Encoding Rules (CER) and Distinguished Encoding Rules 1401 (DER)", ISO/IEC 8825-1:2002, 2002. 1403 12.2. Informative References 1405 [clear-as-mud] 1406 "Clear as MUD: Generating, Validating and Applying IoT 1407 Behaviorial Profiles", October 2019, 1408 . 1410 [cryto-vulnerability] 1411 Perez, B., "Exploiting the Windows CryptoAPI 1412 Vulnerability", January 2020, 1413 . 1416 [I-D.ietf-opsawg-mud-iot-dns-considerations] 1417 Richardson, M. and W. Pan, "Operational Considerations for 1418 use of DNS in IoT devices", Work in Progress, Internet- 1419 Draft, draft-ietf-opsawg-mud-iot-dns-considerations-03, 18 1420 January 2022, . 1423 [I-D.ietf-tls-esni] 1424 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 1425 Encrypted Client Hello", Work in Progress, Internet-Draft, 1426 draft-ietf-tls-esni-14, 13 February 2022, 1427 . 1430 [I-D.ietf-uta-tls13-iot-profile] 1431 Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for 1432 the Internet of Things", Work in Progress, Internet-Draft, 1433 draft-ietf-uta-tls13-iot-profile-03, 25 October 2021, 1434 . 1437 [malware] Anderson, B., Paul, S., and D. McGrew, "Deciphering 1438 Malware’s use of TLS (without Decryption)", July 2016, 1439 . 1441 [malware-doh] 1442 Cimpanu, C., "First-ever malware strain spotted abusing 1443 new DoH (DNS over HTTPS) protocol", July 2019, 1444 . 1447 [malware-tls] 1448 Anderson, B. and D. McGrew, "TLS Beyond the Browser: 1449 Combining End Host and Network Data to Understand 1450 Application Behavior", October 2019, 1451 . 1453 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1454 the Network Configuration Protocol (NETCONF)", RFC 6020, 1455 DOI 10.17487/RFC6020, October 2010, 1456 . 1458 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1459 Extensions: Extension Definitions", RFC 6066, 1460 DOI 10.17487/RFC6066, January 2011, 1461 . 1463 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1464 of Named Entities (DANE) Transport Layer Security (TLS) 1465 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1466 2012, . 1468 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1469 "Transport Layer Security (TLS) Application-Layer Protocol 1470 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1471 July 2014, . 1473 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 1474 Security (TLS) and Datagram Transport Layer Security 1475 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 1476 . 1478 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1479 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1480 2015, . 1482 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1483 "Recommendations for Secure Use of Transport Layer 1484 Security (TLS) and Datagram Transport Layer Security 1485 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1486 2015, . 1488 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1489 Security (TLS) / Datagram Transport Layer Security (DTLS) 1490 Profiles for the Internet of Things", RFC 7925, 1491 DOI 10.17487/RFC7925, July 2016, 1492 . 1494 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1495 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1496 . 1498 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1499 Writing an IANA Considerations Section in RFCs", BCP 26, 1500 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1501 . 1503 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1504 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1505 . 1507 [RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport 1508 Layer Security (TLS) Extension for Token Binding Protocol 1509 Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 1510 2018, . 1512 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1513 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1514 . 1516 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1517 Description Specification", RFC 8520, 1518 DOI 10.17487/RFC8520, March 2019, 1519 . 1521 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1522 Things (IoT) Security: State of the Art and Challenges", 1523 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1524 . 1526 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1527 "Object Security for Constrained RESTful Environments 1528 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1529 . 1531 [X501] "Information Technology - Open Systems Interconnection - 1532 The Directory: Models", ITU-T X.501, 1993. 1534 Authors' Addresses 1535 Tirumaleswar Reddy 1536 McAfee, Inc. 1537 Embassy Golf Link Business Park 1538 Bangalore 560071 1539 Karnataka 1540 India 1541 Email: kondtir@gmail.com 1543 Dan Wing 1544 Citrix Systems, Inc. 1545 4988 Great America Pkwy 1546 Santa Clara, CA 95054 1547 United States of America 1548 Email: danwing@gmail.com 1550 Blake Anderson 1551 Cisco Systems, Inc. 1552 170 West Tasman Dr 1553 San Jose, CA 95134 1554 United States of America 1555 Email: blake.anderson@cisco.com