idnits 2.17.1 draft-reddy-opsawg-mud-tls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 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 409 has weird spacing: '...warding ide...' -- The document date (September 3, 2019) is 1689 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 642 -- Looks like a reference, but probably isn't: '4865' on line 642 -- Looks like a reference, but probably isn't: '4866' on line 642 -- Looks like a reference, but probably isn't: '4867' on line 642 -- Looks like a reference, but probably isn't: '10' on line 643 -- Looks like a reference, but probably isn't: '29' on line 644 == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-10 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-32 ** 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-26 == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-05 == Outdated reference: A later version (-08) exists of draft-reddy-dprive-bootstrap-dns-server-04 Summary: 2 errors (**), 0 flaws (~~), 8 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: March 6, 2020 Citrix 6 September 3, 2019 8 MUD (D)TLS profiles for IoT devices 9 draft-reddy-opsawg-mud-tls-01 11 Abstract 13 This memo extends Manufacturer Usage Description (MUD) to model DTLS 14 and TLS usage. This allows a network element to notice abnormal DTLS 15 or TLS usage which has been strong indicator of other software 16 running on the endpoint, typically malware. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 6, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Overview of MUD (D)TLS profiles for IoT devices . . . . . . . 4 55 4. (D)TLS 1.3 handshake . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Full (D)TLS 1.3 handshake inspection . . . . . . . . . . 5 57 4.2. Encrypted SNI . . . . . . . . . . . . . . . . . . . . . . 6 58 5. (D)TLS profile YANG module . . . . . . . . . . . . . . . . . 7 59 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 9 60 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9 61 6. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 14 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 64 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 67 10.2. Informative References . . . . . . . . . . . . . . . . . 16 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 70 1. Introduction 72 Encryption is necessary to protect the privacy of end users using IoT 73 devices. In a network setting, TLS [RFC8446] and DTLS 74 [I-D.ietf-tls-dtls13] are the dominant protocols to provide 75 encryption for IoT device traffic. Unfortunately in conjunction with 76 IoT applications rise of encryption, malware is also using encryption 77 which thwarts network-based analysis such as deep packet inspection 78 (DPI). Other mechanisms are needed to notice malware is running on 79 the IoT device. 81 Malware frequently uses its own libraries for its activities, and 82 those libraries are re-used much like any other software engineering 83 project. Research [malware] indicates there are observable 84 differences in how malware uses encryption compared with non-malware 85 uses encryption. There are several interesting findings specific to 86 DTLS and TLS which were found common to malware: 88 o Older and weaker cryptographic parameters (e.g., 89 TLS_RSA_WITH_RC4_128_SHA). 91 o TLS SNI and server certificates are composed of subjects with 92 characteristics of a domain generation algorithm (DGA) (e.g., 93 www.33mhwt2j.net). 95 o Higher use of self-signed certificates compared with typical 96 legitimate software. 98 o Discrepancies in the server name indication (SNI) TLS extension in 99 the ClientHello message and the DNS names in the 100 SubjectAltName(SAN) X.509 extension in the server certificate 101 message. 103 o Discrepancies in the key exchange algorithm and the client public 104 key length in comparison with legitimate flows. As a reminder, 105 Client Key Exchange message has been removed from TLS 1.3. 107 o Lower diversity in TLS client advertised TLS extensions compared 108 to legitimate clients. 110 If observable (D)TLS profile parameters are used, the following 111 functions are possible which have a the favorable impact on network 112 security: 114 o Permit intended DTLS or TLS use and to block malicious DTLS or TLS 115 use. This is superior to the layer 3 and layer 4 ACLs of 116 Manufacturer Usage Description Specification (MUD) [RFC8520] which 117 are not suitable for broad communication patterns. 119 o Ensure TLS certificates are valid. Several TLS deployments have 120 been vulnerable to active Man-In-The-Middle (MITM) attacks because 121 of lack of certificate validation. By observing (D)TLS profile 122 parameters, a network element can detect when the TLS SNI 123 mismatches the SubjectAltName and detect when the server's 124 certificate is invalid, and alert those situations. In TLS 1.2, 125 the ClientHello, ServerHello and Certificate messages are all sent 126 in clear-text, however in TLS 1.3, the Certificate message is 127 encrypted thereby hiding the server identity from any 128 intermediary. In TLS 1.3, the middle-box needs to act as a TLS 129 proxy to validate the server certificate and to detect TLS SNI 130 mismatch with the server certificate. 132 o Support new communication patterns. IoT device can learn a new 133 capability, and the new capability changes the way the IoT device 134 communicates with other devices located in the local network and 135 Internet. In other words, if IP addresses and domain names the 136 IoT device connects to rapidly changes based on a new capability 137 and MUD rules using ACLs cannot be rapidly updated. In such a 138 case, observable (D)TLS profile parameters can be used to permit 139 intended use and to block malicious behaviour of IoT device. 141 This document extends MUD [RFC8520] to model observable (D)TLS 142 profile parameters. Using these (D)TLS profile parameters, an active 143 MUD-enforcing firewall can identify MUD non-compliant DTLS and TLS 144 behavior that can indicate malware is running on the IoT device. 145 This detection can prevent malware download, block access to 146 malicious domains, enforce use of strong ciphers, stop data 147 exfiltration, etc. In addition, organizations may have policies 148 around acceptable ciphers and certificates on the websites the IoT 149 devices connect to. Examples include no use of old and less secure 150 versions of TLS, no use of self-signed certificates, deny-list or 151 accept-list of Certificate Authorities, valid certificate expiration 152 time, etc. These policies can be enforced by observing the (D)TLS 153 profile parameters. Enterprise firewall can use the IoT device's 154 (D)TLS profile parameters to identify legitimate flows by observation 155 of (D)TLS sessions, and can make inferences to permit legitimate 156 flows and to block malicious flows. The proposed technique is also 157 suitable in deployments where decryption techniques are not ideal due 158 to privacy concerns, non-cooperating end-points and expense. 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119][RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 "(D)TLS" is used for statements that apply to both Transport Layer 169 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 170 Specific terms are used for any statement that applies to either 171 protocol alone. 173 3. Overview of MUD (D)TLS profiles for IoT devices 175 In Enterprise networks, protection and detection are typically done 176 both on end hosts and in the network. Host agents have deep 177 visibility on the devices where they are installed, whereas the 178 network has broader visibility. Installing host agents may not be a 179 viable option on IoT devices, and network-based security can only be 180 used to protect such IoT devices. (D)TLS profile parameters of IoT 181 device can be used by middle-boxes to detect and block malware 182 communication, while at the same time preserving the privacy of 183 legitimate uses of encryption. Middle-boxes need not proxy (D)TLS 184 but can passively observe the parameters of (D)TLS handshakes from 185 IoT devices and gain good visibility into TLS 1.0 to 1.2 parameters 186 and partial visibility into TLS 1.3 parameters. Malicious agents can 187 try to use the (D)TLS profile parameters as legitimate agents to 188 evade detection but it becomes a challenge to mimic the behavior of 189 various IoT device types and IoT device models from several 190 manufacturers. In other words, malware developers will have to 191 develop malicious agents per IoT device type, manufacturer and model 192 (which will be several thousands), infect the device with specific 193 malware agent and will have keep up with the updates to (D)TLS 194 profile parameters of IoT devices. Further, the malware command and 195 control server certificates needs to be signed by the same certifying 196 authorities trusted by the IoT devices. 198 The compromised IoT devices are typically used for launching DDoS 199 attacks (Section 3 of [RFC8576]) on victims while the owner/ 200 administrator of the network is not aware about such misbehaviors. 201 Some of the DDoS attacks like Slowloris and Transport Layer Security 202 (TLS) re-negotiation can be detected by observing the (D)TLS profile 203 parameters. For example, the victim server certificate need not be 204 signed by the same certifying authorities trusted by the IoT device. 206 4. (D)TLS 1.3 handshake 208 In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since 209 all (D)TLS handshake messages excluding the ClientHello message are 210 encrypted. (D)TLS 1.3 has introduced new extensions in the handshake 211 record layers called Encrypted Extensions. Using these extensions 212 handshake messages will be encrypted and network devices (such as a 213 firewall) are incapable deciphering the handshake, thus cannot view 214 the server certificate. However, a few parameters in the ServerHello 215 are still visible such as the chosen cipher. 217 4.1. Full (D)TLS 1.3 handshake inspection 219 To obtain more visibility into negotiated TLS 1.3 parameters, a 220 middlebox needs to act as a (D)TLS 1.3 proxy. The middlebox MUST 221 follow the behaviour explained in Section 9.3 of [RFC8446] to act as 222 a compliant (D)TLS 1.3 proxy. 224 To function as a (D)TLS proxy the middlebox creates a signed 225 certificate using itself as a certificate authority. That 226 certificate authority has to be trusted by the (D)TLS client. The 227 following steps explain the mechanism to automatically bootstrap IoT 228 devices with the middlebox's CA certificate. 230 Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed in 231 [I-D.ietf-anima-bootstrapping-keyinfra] provides a solution for 232 secure automated bootstrap of devices. BRSKI specifies means to 233 provision credentials on devices to be used to operationally access 234 networks. In addition, BRSKI provides an automated mechanism for the 235 bootstrap distribution of CA certificates from the Enrollment over 236 Secure Transport (EST) [RFC7030] server. The IoT device can use 237 BRSKI to automatically bootstrap the IoT device using the IoT 238 manufacturer provisioned X.509 certificate, in combination with a 239 registrar provided by the local network and IoT device manufacturer's 240 authorizing service (MASA). 242 1. The IoT device authenticates to the local network using the IoT 243 manufacturer provisioned X.509 certificate. The IoT device can 244 request and get a voucher from the MASA service via the 245 registrar. The voucher is signed by the MASA service and 246 includes the local network's CA public key. 248 2. The IoT device validates the signed voucher using the 249 manufacturer installed trust anchor associated with the MASA, 250 stores the CA's public key and validates the provisional TLS 251 connection to the registrar. 253 3. The IoT device requests the full EST distribution of current CA 254 certificates (Section 5.9.1 in 255 [I-D.ietf-anima-bootstrapping-keyinfra]) from the registrar 256 operating as a BRSKI-EST server. The IoT device stores the CA 257 certificates as Explicit Trust Anchor database entries. The IoT 258 device uses the Explicit Trust Anchor database to validate the 259 server certificate. 261 4. The middle-box uses the "supported_versions" TLS extension 262 (defined in TLS 1.3 to negotiate the supported TLS versions 263 between client and server) to determine the TLS version. During 264 the (D)TLS handshake, If (D)TLS version 1.3 is used, the middle- 265 box ((D)TLS proxy) modifies the certificate provided by the 266 server and signs it with the private key from the local CA 267 certificate. The middle-box has visibility into further 268 exchanges between the IoT device and server which enables it to 269 inspect the (D)TLS 1.3 handshake, enforce the MUD (D)TLS profile 270 and can inspect subsequent network traffic. 272 5. The IoT device uses the Explicit Trust Anchor database to 273 validate the server certificate. 275 4.2. Encrypted SNI 277 To increase privacy, encrypted SNI (ESNI, 278 [I-D.ietf-tls-sni-encryption]) prevents passive observation of the 279 TLS Server Name Indication which improves privacy. To effectively 280 provide that privacy protection, SNI encryption needs to be used in 281 conjunction with DNS encryption (e.g., DNS-over-(D)TLS or DNS-over- 282 HTTPS). An in-line network device (e.g., firewall) passively 283 inspecting an encrypted SNI (D)TLS handshake cannot observe the 284 encrypted SNI nor observe the encrypted DNS traffic. If an IoT 285 device is pre-configured to use public DNS-over-(D)TLS or DNS-over- 286 HTTPS servers, the middle-box needs to act as a DNS-over-TLS or DNS- 287 over-HTTPS proxy and replace the esni_keys in the ESNI record with 288 the middle box's esni_keys. Instead of an unappealing DNS-over-TLS 289 or DNS-over-HTTPS proxy, the IoT device can be bootstrapped to 290 discover and authenticate DNS-over-(D)TLS and DNS-over-HTTPS servers 291 provided by a local network using 292 [I-D.reddy-dprive-bootstrap-dns-server] and [I-D.sah-resinfo-doh]. 293 The local DNS-over-(D)TLS and DNS-over-HTTPS server replaces the 294 sni_keys in the ESNI record with the middle box's esni_keys. 296 Note that if an IoT device is pre-configured to use public DNS- 297 over-(D)TLS or DNS-over-HTTPS servers, the MUD policy enforcement 298 point is moved to that public server, which cannot enforce the MUD 299 policy based on domain names (Section 8 of [RFC8520]). Thus the use 300 of a public DNS-over-(D)TLS or DNS-over-HTTPS server is incompatible 301 with MUD in general. A local DNS server is necessary to allow MUD 302 policy enforcement on the local network. 304 5. (D)TLS profile YANG module 306 This document specifies a YANG module for representing (D)TLS 307 profile. The (D)TLS profile YANG module provides a method for 308 firewall to observe the (D)TLS profile parameters in the (D)TLS 309 handshake to permit intended use and to block malicious behavior. 310 This module uses the common YANG types defined in [RFC6991] , rules 311 defined in [RFC8519] and cryptographic types defined in 312 [I-D.ietf-netconf-crypto-types]. 314 The (D)TLS profiles and the parameters in each (D)TLS profile include 315 the following: 317 o Profile name 319 o (D)TLS version in ClientHello.legacy_version 321 o (D)TLS versions supported by the IoT device. As a reminder, 322 "supported_versions" extension defined in (D)TLS 1.3 is used by 323 the client to indicate which versions of (D)TLS it supports and a 324 client is considered to be attempting to negotiate (D)TLS 1.3 if 325 the ClientHello contains a "supported_versions" extension with 326 0x0304 contained in its body. 328 o If GREASE [I-D.ietf-tls-grease] (Generate Random Extensions And 329 Sustain Extensibility) values are offered by the client or not. 331 o List of supported symmetric encryption algorithms 333 o List of supported compression methods 335 o List of extension types 336 o List of trust anchor certificates used by the IoT device. If the 337 server certificate is signed by one of the trust anchors, the 338 middle-box continues with the connection as normal. Otherwise, 339 the middle-box will react as if the the server certificate 340 validation has failed and takes appropriate action (e.g, block the 341 (D)TLS session). Note that server certificate is encrypted in 342 (D)TLS 1.3 and the middle-box without acting as (D)TLS proxy 343 cannot validate the server certificate. 345 o List of SPKI pin set pre-configured on the client to validate 346 self-signed server certificates or raw public keys. A SPKI pin 347 set is a cryptographic digest to "pin" public key information in a 348 manner similar to HTTP Public Key Pinning (HPKP) [RFC7469]. If 349 SPKI pin set is present in the (D)TLS profile of a IoT device and 350 the server certificate does not pass the PKIX certification path 351 validation, the middle-box computes the SPKI Fingerprint for the 352 public key found in the server's certificate (or in the raw public 353 key, if the server provides that instead). If a computed 354 fingerprint exactly matches one of the SPKI pin sets in the (D)TLS 355 profile, the middle-box continues with the connection as normal. 356 Otherwise, the middle-box will act on the SPKI validation failure 357 and takes appropriate action. 359 o Cryptographic hash algorithm used to generate the SPKI pinsets 361 o List of pre-shared key exchange modes 363 o List of DHE or ECDHE groups supported by the client 365 o List signature algorithms the client can validate in X.509 server 366 certificates 368 o List of client key exchange algorithms and the client public key 369 lengths in versions prior to (D)TLS 1.3 371 The (D)TLS profile parameters MUST NOT include the GREASE values for 372 extension types, supported groups, signature algorithms, (D)TLS 373 versions, pre-shared key exchange modes and cipher suites. Note that 374 the GREASE values are random and peers will ignore these values and 375 interoperate. 377 If the (D)TLS profile parameters are not observed in a (D)TLS session 378 from the IoT device, the default behaviour is to block the (D)TLS 379 session. 381 5.1. Tree Structure 383 This document augments the "ietf-mud" MUD YANG module defined in 384 [RFC8520] for signaling the IoT device (D)TLS profile. This document 385 defines the YANG module "reddy-opsawg-mud-tls-profile", which has the 386 following tree structure: 388 module: reddy-opsawg-mud-tls-profile 389 augment /mud:mud/mud:from-device-policy: 390 +--rw client-profile 391 +--rw tls-profiles* [profile-name] 392 +--rw profile-name string 393 +--rw protocol-version? uint16 394 +--rw supported_versions* uint16 395 +--rw grease_extension? boolean 396 +--rw encryption-algorithms* encryption-algorithm 397 +--rw compression-methods* compression-method 398 +--rw extension-types* extension-type 399 +--rw acceptlist-ta-certs* ct:trust-anchor-cert-cms 400 +--rw SPKI-pin-sets* SPKI-pin-set 401 +--rw SPKI-hash-algorithm ct:hash-algorithm-t 402 +--rw psk-key-exchange-modes* psk-key-exchange-mode 403 +--rw supported-groups* supported-group 404 +--rw signature-algorithms* signature-algorithm 405 +--rw client-public-keys 406 | +--rw key-exchange-algorithms* key-exchange-algorithm 407 | +--rw client-public-key-lengths* client-public-key-length 408 +--rw actions 409 +--rw forwarding identityref 411 5.2. YANG Module 413 module reddy-opsawg-mud-tls-profile { 414 yang-version 1.1; 415 namespace "urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile"; 416 prefix mud-tls-profile; 418 import ietf-crypto-types { 419 prefix ct; 420 reference "draft-ietf-netconf-crypto-types-01: 421 Common YANG Data Types for Cryptography"; 422 } 424 import ietf-inet-types { 425 prefix inet; 426 reference "Section 4 of RFC 6991"; 427 } 428 import ietf-mud { 429 prefix mud; 430 reference "RFC 8520"; 431 } 433 import ietf-access-control-list { 434 prefix ietf-acl; 435 reference 436 "RFC 8519: YANG Data Model for Network Access 437 Control Lists (ACLs)"; 438 } 440 organization 441 "IETF Operations and Management Area Working Group Working Group"; 442 contact 443 "Editor: Konda, Tirumaleswar Reddy 444 "; 446 description 447 "This module contains YANG definition for the IoT device 448 (D)TLS profile. 450 Copyright (c) 2019 IETF Trust and the persons identified as 451 authors of the code. All rights reserved. 453 Redistribution and use in source and binary forms, with or 454 without modification, is permitted pursuant to, and subject 455 to the license terms contained in, the Simplified BSD License 456 set forth in Section 4.c of the IETF Trust's Legal Provisions 457 Relating to IETF Documents 458 (http://trustee.ietf.org/license-info). 460 This version of this YANG module is part of RFC XXXX; see 461 the RFC itself for full legal notices."; 463 revision 2019-06-12 { 464 description 465 "Initial revision."; 466 } 468 typedef compression-method { 469 type uint8; 470 description "Compression method."; 471 } 473 typedef extension-type { 474 type uint16; 475 description "Extension type."; 477 } 479 typedef encryption-algorithm { 480 type uint16; 481 description "Encryption algorithms."; 482 } 484 typedef supported-group { 485 type uint16; 486 description "supported DHE or ECDHE group."; 487 } 489 typedef SPKI-pin-set { 490 type binary; 491 description "Subject Public Key Info pin set."; 492 } 494 typedef signature-algorithm { 495 type uint16; 496 description "Signature algorithm"; 497 } 499 typedef key-exchange-algorithm { 500 type uint8; 501 description "key exchange algorithm"; 502 } 504 typedef psk-key-exchange-mode { 505 type uint8; 506 description "pre-shared key exchange mode"; 507 } 509 typedef client-public-key-length { 510 type uint8; 511 description "client public key length"; 512 } 514 augment "/mud:mud/mud:from-device-policy" { 515 container client-profile { 516 list tls-profiles { 517 key "profile-name"; 518 description 519 "(D)TLS version profiles supported by the client"; 520 leaf profile-name { 521 type string { 522 length "1..64"; 523 } 524 description 525 "The name of (D)TLS profile; space and special 526 characters are not allowed."; 527 } 528 leaf protocol-version { 529 type uint16; 530 description "Legacy protocol version."; 531 } 532 leaf-list supported_versions { 533 type uint16; 534 description 535 "TLS versions supported by the client indicated 536 in the supported_versions extension in (D)TLS 1.3."; 537 } 538 leaf Grease_extension { 539 type boolean; 540 description 541 "If set to 'true', Grease extension values are offered by 542 the client."; 543 } 544 leaf-list encryption-algorithms { 545 type encryption-algorithm; 546 description "Encryption algorithms"; 547 } 548 leaf-list compression-methods { 549 type compression-method; 550 description "Compression methods"; 551 } 552 leaf-list extension-types { 553 type extension-type; 554 description "Extension Types"; 555 } 556 leaf-list acceptlist-ta-certs { 557 type ct:trust-anchor-cert-cms; 558 description 559 "A list of trust anchor certificates used by the client."; 560 } 561 leaf-list SPKI-pin-sets { 562 type SPKI-pin-set; 563 description 564 "A list of SPKI pin sets pre-configured on the client 565 to validate self-signed server certificate or 566 raw public key."; 567 } 568 leaf SPKI-hash-algorithm { 569 type ct:hash-algorithm-t; 570 description 571 "cryptographic hash algorithm used to generate the 572 SPKI pinset."; 574 } 575 leaf-list psk-key-exchange-modes { 576 type psk-key-exchange-mode; 577 description 578 "pre-shared key exchange modes"; 579 } 580 leaf-list supported-groups { 581 type supported-group; 582 description 583 "A list of DHE or ECDHE groups supported by the client."; 584 } 585 leaf-list signature-algorithms { 586 type signature-algorithm; 587 description 588 "A list signature algorithms the client can validate 589 in X.509 certificates."; 590 } 591 container client-public-keys { 592 leaf-list key-exchange-algorithms { 593 type key-exchange-algorithm; 594 description 595 "Key exchange algorithms supported by the client"; 596 } 597 leaf-list client-public-key-lengths { 598 type client-public-key-length; 599 description 600 "client public key lengths"; 601 } 602 } 603 container actions { 604 description 605 "Definitions of action for this profile."; 606 leaf forwarding { 607 type identityref { 608 base ietf-acl:forwarding-action; 609 } 610 mandatory true; 611 description 612 "Specifies the forwarding action for the (D)TLS profile."; 613 reference 614 "RFC 8519: YANG Data Model for Network Access 615 Control Lists (ACLs)"; 616 } 617 } 618 } 619 } 620 } 621 } 622 6. MUD File Example 624 This example below contains (D)TLS profile parameters for a IoT 625 device. JSON encoding of YANG modelled data [RFC7951] is used to 626 illustrate the example. 628 { 629 "ietf-mud:mud": { 630 "mud-version": 1, 631 "mud-url": "https://example.com/IoTDevice", 632 "last-update": "2019-18-06T03:56:40.105+10:00", 633 "cache-validity": 100, 634 "is-supported": true, 635 "systeminfo": "IoT device name", 636 "reddy-opsawg-mud-tls-profile:from-device-policy": { 637 "client-profile": { 638 "tls-version-profile" : [ 639 { 640 "protocol-version" : 771, 641 "supported_versions_ext" : "FALSE", 642 "encryption-algorithms" : [31354, 4865, 4866, 4867], 643 "extension-types" : [10], 644 "supported-groups" : [29], 645 "actions": { 646 "forwarding": "accept" 647 } 648 } 649 ] 650 } 651 } 652 } 653 } 655 7. Security Considerations 657 Security considerations in [RFC8520] need to be taken into 658 consideration. 660 8. IANA Considerations 662 This document requests IANA to register the following URIs in the 663 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 665 URI: urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile 666 Registrant Contact: The IESG. 667 XML: N/A; the requested URI is an XML namespace. 669 9. Acknowledgments 671 Thanks to Shashank Jain and Harsha Joshi for the discussion and 672 comments. 674 10. References 676 10.1. Normative References 678 [I-D.ietf-netconf-crypto-types] 679 Watsen, K. and H. Wang, "Common YANG Data Types for 680 Cryptography", draft-ietf-netconf-crypto-types-10 (work in 681 progress), July 2019. 683 [I-D.ietf-tls-dtls13] 684 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 685 Datagram Transport Layer Security (DTLS) Protocol Version 686 1.3", draft-ietf-tls-dtls13-32 (work in progress), July 687 2019. 689 [I-D.ietf-tls-grease] 690 Benjamin, D., "Applying GREASE to TLS Extensibility", 691 draft-ietf-tls-grease-04 (work in progress), August 2019. 693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", BCP 14, RFC 2119, 695 DOI 10.17487/RFC2119, March 1997, 696 . 698 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 699 DOI 10.17487/RFC3688, January 2004, 700 . 702 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 703 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 704 January 2012, . 706 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 707 RFC 6991, DOI 10.17487/RFC6991, July 2013, 708 . 710 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 711 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 712 May 2017, . 714 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 715 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 716 . 718 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 719 "YANG Data Model for Network Access Control Lists (ACLs)", 720 RFC 8519, DOI 10.17487/RFC8519, March 2019, 721 . 723 10.2. Informative References 725 [I-D.ietf-anima-bootstrapping-keyinfra] 726 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 727 and K. Watsen, "Bootstrapping Remote Secure Key 728 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 729 keyinfra-26 (work in progress), August 2019. 731 [I-D.ietf-tls-sni-encryption] 732 Huitema, C. and E. Rescorla, "Issues and Requirements for 733 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-05 734 (work in progress), August 2019. 736 [I-D.reddy-dprive-bootstrap-dns-server] 737 K, R., Wing, D., Richardson, M., and M. Boucadair, "A 738 Bootstrapping Procedure to Discover and Authenticate DNS- 739 over-(D)TLS and DNS-over-HTTPS Servers", draft-reddy- 740 dprive-bootstrap-dns-server-04 (work in progress), June 741 2019. 743 [I-D.sah-resinfo-doh] 744 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 745 Information: "doh"", draft-sah-resinfo-doh-00 (work in 746 progress), May 2019. 748 [malware] Anderson, B., Paul, S., and D. McGrew, "Deciphering 749 Malware's use of TLS (without Decryption)", July 2016, 750 . 752 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 753 "Enrollment over Secure Transport", RFC 7030, 754 DOI 10.17487/RFC7030, October 2013, 755 . 757 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 758 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 759 2015, . 761 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 762 RFC 7951, DOI 10.17487/RFC7951, August 2016, 763 . 765 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 766 Description Specification", RFC 8520, 767 DOI 10.17487/RFC8520, March 2019, 768 . 770 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 771 Things (IoT) Security: State of the Art and Challenges", 772 RFC 8576, DOI 10.17487/RFC8576, April 2019, 773 . 775 Authors' Addresses 777 Tirumaleswar Reddy 778 McAfee, Inc. 779 Embassy Golf Link Business Park 780 Bangalore, Karnataka 560071 781 India 783 Email: kondtir@gmail.com 785 Dan Wing 786 Citrix Systems, Inc. 787 4988 Great America Pkwy 788 Santa Clara, CA 95054 789 USA 791 Email: danwing@gmail.com