idnits 2.17.1 draft-reddy-opsawg-mud-tls-00.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 282 has weird spacing: '...warding ide...' -- The document date (August 6, 2019) is 1718 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 603 -- Looks like a reference, but probably isn't: '4865' on line 603 -- Looks like a reference, but probably isn't: '4866' on line 603 -- Looks like a reference, but probably isn't: '4867' on line 603 -- Looks like a reference, but probably isn't: '10' on line 604 -- Looks like a reference, but probably isn't: '29' on line 605 == Unused Reference: 'RFC7478' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'RFC8445' is defined on line 727, but no explicit reference was found in the text == 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 == Outdated reference: A later version (-04) exists of draft-ietf-tls-grease-03 ** 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-24 == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-04 == Outdated reference: A later version (-08) exists of draft-reddy-dprive-bootstrap-dns-server-04 Summary: 2 errors (**), 0 flaws (~~), 11 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: February 7, 2020 Citrix 6 August 6, 2019 8 MUD (D)TLS profiles for IoT devices 9 draft-reddy-opsawg-mud-tls-00 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 February 7, 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 profile YANG module . . . . . . . . . . . . . . . . . 5 56 4.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 6 57 4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. (D)TLS 1.3 handshake . . . . . . . . . . . . . . . . . . . . 11 59 5.1. Encrypted SNI . . . . . . . . . . . . . . . . . . . . . . 11 60 5.2. Full (D)TLS 1.3 handshake inspection . . . . . . . . . . 12 61 6. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 13 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 64 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 67 10.2. Informative References . . . . . . . . . . . . . . . . . 15 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 discusses the favorable impact on network security: 113 o Although IoT devices that have a single or small number of uses 114 might have very broad communication patterns. In such a case, MUD 115 rules using ACLs on its own is not suitable for these IoT devices 116 but observable (D)TLS profile parameters can be used for such IoT 117 devices to permit intended use and to block malicious behaviour of 118 IoT devices. 120 o Several TLS deployments have been vulnerable to active Man-In-The- 121 Middle (MITM) attacks because of lack of certificate validation. 122 By observing (D)TLS profile parameters, a network element can 123 detect when the TLS SNI mismatches the SubjectAltName and detect 124 when the server's certificate is invalid, and alert those 125 situations. 127 o IoT device can learn a new skill, and the new skill changes the 128 way the IoT device communicates with other devices located in the 129 local network and Internet. In other words, if IP addresses and 130 domain names the IoT device connects to rapidly changes and MUD 131 rules using ACLs cannot be rapidly updated, observable (D)TLS 132 profile parameters can be used to permit intended use and to block 133 malicious behaviour of IoT device. 135 This document extends MUD [RFC8520] to model observable (D)TLS 136 profile parameters. Using these (D)TLS profile parameters, an active 137 MUD-enforcing firewall can identify MUD non-compliant DTLS and TLS 138 behavior that can indicate malware is running on the IoT device. 139 This detection can prevent malware download, block access to 140 malicious domains, enforce use of strong ciphers, stop data 141 exfiltration, etc. In addition, organizations may have policies 142 around acceptable ciphers and certificates on the websites the IoT 143 devices connect to. Examples include no use of old and less secure 144 versions of TLS, no use of self-signed certificates, deny-list or 145 accept-list of Certificate Authorities, valid certificate expiration 146 time, etc. These policies can be enforced by observing the (D)TLS 147 profile parameters. Enterprise firewall can use the IoT device's 148 (D)TLS profile parameters to identify legitimate flows by observation 149 of (D)TLS sessions, and can make inferences to permit legitimate 150 flows and to block malicious flows. The proposed technique is also 151 suitable in deployments where decryption techniques are not ideal due 152 to privacy concerns, non-cooperating end-points and expense. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in BCP 159 14 [RFC2119][RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 "(D)TLS" is used for statements that apply to both Transport Layer 163 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 164 Specific terms are used for any statement that applies to either 165 protocol alone. 167 3. Overview of MUD (D)TLS profiles for IoT devices 169 In Enterprise networks, protection and detection are typically done 170 both on end hosts and in the network. Host agents have deep 171 visibility on the devices where they are installed, whereas the 172 network has broader visibility. Installing host agents may not be a 173 viable option on IoT devices, and network-based security can only be 174 used to protect such IoT devices. (D)TLS profile parameters of IoT 175 device can be used by middle-boxes to detect and block malware 176 communication, while at the same time preserving the privacy of 177 legitimate uses of encryption. Middle-boxes need not proxy (D)TLS 178 but can passively observe the parameters of (D)TLS handshakes from 179 IoT devices and gain good visibility into TLS 1.0 to 1.2 parameters 180 and partial visibility into TLS 1.3 parameters. Malicious agents can 181 try to use the (D)TLS profile parameters as legitimate agents to 182 evade detection but it becomes a challenge to mimic the behavior of 183 various IoT device types and IoT device models from several 184 manufacturers. In other words, malware developers will have to 185 develop malicious agents per IoT device type, manufacturer and model 186 (which will be several thousands), infect the device with specific 187 malware agent and will have keep up with the updates to (D)TLS 188 profile parameters of IoT devices. Further, the malware command and 189 control server certificates needs to be signed by the same certifying 190 authorities trusted by the IoT devices. 192 4. (D)TLS profile YANG module 194 This document specifies a YANG module for representing (D)TLS 195 profile. The (D)TLS profile YANG module provides a method for 196 firewall to observe the (D)TLS profile parameters in the (D)TLS 197 handshake to permit intended use and to block malicious behavior. 198 This module uses the common YANG types defined in [RFC6991] , rules 199 defined in [RFC8519] and cryptographic types defined in 200 [I-D.ietf-netconf-crypto-types]. 202 The (D)TLS profiles and the parameters in each (D)TLS profile include 203 the following: 205 o Profile name 207 o (D)TLS version in ClientHello.legacy_version 209 o (D)TLS versions supported by the IoT device. As a reminder, 210 "supported_versions" extension defined in (D)TLS 1.3 is used by 211 the client to indicate which versions of (D)TLS it supports and a 212 client is considered to be attempting to negotiate (D)TLS 1.3 if 213 the ClientHello contains a "supported_versions" extension with 214 0x0304 contained in its body. 216 o If GREASE [I-D.ietf-tls-grease] (Generate Random Extensions And 217 Sustain Extensibility) values are offered by the client or not. 219 o List of supported symmetric encryption algorithms 221 o List of supported compression methods 223 o List of extension types 225 o List of trust anchor certificates used by the IoT device. Note 226 that server certificate is encrypted in (D)TLS 1.3 and the middle- 227 box without acting as (D)TLS proxy cannot validate the server 228 certificate. 230 o List of SPKI pin sets pre-configured on the client to validate 231 self-signed server certificates or raw public keys 233 o Cryptographic hash algorithm used to generate the SPKI pinsets 235 o List of pre-shared key exchange modes 237 o List of DHE or ECDHE groups supported by the client 238 o List signature algorithms the client can validate in X.509 server 239 certificates 241 o List of client key exchange algorithms and the client public key 242 lengths in versions prior to (D)TLS 1.3 244 The (D)TLS profile parameters MUST NOT include the GREASE values for 245 extension types, supported groups, signature algorithms, (D)TLS 246 versions, pre-shared key exchange modes and cipher suites. Note that 247 the GREASE values are random and peers will ignore these values and 248 interoperate. 250 If the (D)TLS profile parameters are not observed in a (D)TLS session 251 from the IoT device, the default behaviour is to block the (D)TLS 252 session. 254 4.1. Tree Structure 256 This document augments the "ietf-mud" MUD YANG module defined in 257 [RFC8520] for signaling the IoT device (D)TLS profile. This document 258 defines the YANG module "reddy-opsawg-mud-tls-profile", which has the 259 following tree structure: 261 module: reddy-opsawg-mud-tls-profile 262 augment /mud:mud/mud:from-device-policy: 263 +--rw client-profile 264 +--rw tls-profiles* [profile-name] 265 +--rw profile-name string 266 +--rw protocol-version? uint16 267 +--rw supported_versions* uint16 268 +--rw grease_extension? boolean 269 +--rw encryption-algorithms* encryption-algorithm 270 +--rw compression-methods* compression-method 271 +--rw extension-types* extension-type 272 +--rw acceptlist-ta-certs* ct:trust-anchor-cert-cms 273 +--rw SPKI-pin-sets* SPKI-pin-set 274 +--rw SPKI-hash-algorithm ct:hash-algorithm-t 275 +--rw psk-key-exchange-modes* psk-key-exchange-mode 276 +--rw supported-groups* supported-group 277 +--rw signature-algorithms* signature-algorithm 278 +--rw client-public-keys 279 | +--rw key-exchange-algorithms* key-exchange-algorithm 280 | +--rw client-public-key-lengths* client-public-key-length 281 +--rw actions 282 +--rw forwarding identityref 284 4.2. YANG Module 286 module reddy-opsawg-mud-tls-profile { 287 yang-version 1.1; 288 namespace "urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile"; 289 prefix mud-tls-profile; 291 import ietf-crypto-types { 292 prefix ct; 293 reference "draft-ietf-netconf-crypto-types-01: 294 Common YANG Data Types for Cryptography"; 295 } 297 import ietf-inet-types { 298 prefix inet; 299 reference "Section 4 of RFC 6991"; 300 } 302 import ietf-mud { 303 prefix mud; 304 reference "RFC 8520"; 305 } 307 import ietf-access-control-list { 308 prefix ietf-acl; 309 reference 310 "RFC 8519: YANG Data Model for Network Access 311 Control Lists (ACLs)"; 312 } 314 organization 315 "IETF Operations and Management Area Working Group Working Group"; 316 contact 317 "Editor: Konda, Tirumaleswar Reddy 318 "; 320 description 321 "This module contains YANG definition for configuring 322 aliases for resources and filtering rules using DOTS 323 data channel. 325 Copyright (c) 2019 IETF Trust and the persons identified as 326 authors of the code. All rights reserved. 328 Redistribution and use in source and binary forms, with or 329 without modification, is permitted pursuant to, and subject 330 to the license terms contained in, the Simplified BSD License 331 set forth in Section 4.c of the IETF Trust's Legal Provisions 332 Relating to IETF Documents 333 (http://trustee.ietf.org/license-info). 335 This version of this YANG module is part of RFC XXXX; see 336 the RFC itself for full legal notices."; 338 revision 2019-06-12 { 339 description 340 "Initial revision."; 341 } 343 typedef compression-method { 344 type uint8; 345 description "Compression method."; 346 } 348 typedef extension-type { 349 type uint16; 350 description "Extension type."; 351 } 353 typedef encryption-algorithm { 354 type uint16; 355 description "Encryption algorithms."; 356 } 358 typedef supported-group { 359 type uint16; 360 description "supported DHE or ECDHE group."; 361 } 363 typedef SPKI-pin-set { 364 type binary; 365 description "Subject Public Key Info pin set."; 366 } 368 typedef signature-algorithm { 369 type uint16; 370 description "Signature algorithm"; 371 } 373 typedef key-exchange-algorithm { 374 type uint8; 375 description "key exchange algorithm"; 376 } 378 typedef psk-key-exchange-mode { 379 type uint8; 380 description "pre-shared key exchange mode"; 381 } 383 typedef client-public-key-length { 384 type uint8; 385 description "client public key length"; 386 } 388 augment "/mud:mud/mud:from-device-policy" { 389 container client-profile { 390 list tls-profiles { 391 key "profile-name"; 392 description 393 "(D)TLS version profiles supported by the client"; 394 leaf profile-name { 395 type string { 396 length "1..64"; 397 } 398 description 399 "The name of (D)TLS profile; space and special 400 characters are not allowed."; 401 } 402 leaf protocol-version { 403 type uint16; 404 description "Legacy protocol version."; 405 } 406 leaf-list supported_versions { 407 type uint16; 408 description 409 "TLS versions supported by the client indicated 410 in the supported_versions extension in (D)TLS 1.3."; 411 } 412 leaf Grease_extension { 413 type boolean; 414 description 415 "If set to 'true', Grease extension values are offered by 416 the client."; 417 } 418 leaf-list encryption-algorithms { 419 type encryption-algorithm; 420 description "Encryption algorithms"; 421 } 422 leaf-list compression-methods { 423 type compression-method; 424 description "Compression methods"; 425 } 426 leaf-list extension-types { 427 type extension-type; 428 description "Extension Types"; 429 } 430 leaf-list acceptlist-ta-certs { 431 type ct:trust-anchor-cert-cms; 432 description 433 "A list of trust anchor certificates used by the client."; 434 } 435 leaf-list SPKI-pin-sets { 436 type SPKI-pin-set; 437 description 438 "A list of SPKI pin sets pre-configured on the client 439 to validate self-signed server certificate or 440 raw public key."; 441 } 442 leaf SPKI-hash-algorithm { 443 type ct:hash-algorithm-t; 444 description 445 "cryptographic hash algorithm used to generate the 446 SPKI pinset."; 447 } 448 leaf-list psk-key-exchange-modes { 449 type psk-key-exchange-mode; 450 description 451 "pre-shared key exchange modes"; 452 } 453 leaf-list supported-groups { 454 type supported-group; 455 description 456 "A list of DHE or ECDHE groups supported by the client."; 457 } 458 leaf-list signature-algorithms { 459 type signature-algorithm; 460 description 461 "A list signature algorithms the client can validate 462 in X.509 certificates."; 463 } 464 container client-public-keys { 465 leaf-list key-exchange-algorithms { 466 type key-exchange-algorithm; 467 description 468 "Key exchange algorithms supported by the client"; 469 } 470 leaf-list client-public-key-lengths { 471 type client-public-key-length; 472 description 473 "client public key lengths"; 474 } 476 } 477 container actions { 478 description 479 "Definitions of action for this profile."; 480 leaf forwarding { 481 type identityref { 482 base ietf-acl:forwarding-action; 483 } 484 mandatory true; 485 description 486 "Specifies the forwarding action for the (D)TLS profile."; 487 reference 488 "RFC 8519: YANG Data Model for Network Access 489 Control Lists (ACLs)"; 490 } 491 } 492 } 493 } 494 } 495 } 497 5. (D)TLS 1.3 handshake 499 In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since 500 all (D)TLS handshake messages excluding the ClientHello message are 501 encrypted. (D)TLS 1.3 has introduced new extensions in the handshake 502 record layers called Encrypted Extensions. Using these extensions 503 handshake messages will be encrypted and network devices (such as a 504 firewall) are incapable deciphering the handshake, thus cannot view 505 the server certificate. However, a few parameters in the ServerHello 506 are still visible such as the chosen cipher. Note that Client Key 507 Exchange message has been removed from (D)TLS 1.3. 509 5.1. Encrypted SNI 511 To increase privacy, encrypted SNI [I-D.ietf-tls-sni-encryption] 512 prevents passive observation of the TLS Server Name Indication and to 513 effectively provide privacy protection, SNI encryption needs to be 514 used in conjunction with DNS encryption (e.g., DNS-over-(D)TLS or 515 DNS- over-HTTPS). Firewall inspecting the (D)TLS 1.3 handshake 516 cannot decrypt encrypted SNI. If an IoT device is configured to use 517 public DNS-over-(D)TLS or DNS- over-HTTPS servers, the policy 518 enforcement point is moved to that public server, which cannot 519 enforce the MUD policy based on domain names (Section 8 of 520 [RFC8520]). Thus the use of a public DNS-over-(D)TLS or DNS- over- 521 HTTPS server is incompatible with MUD. A local DNS server is 522 necessary to allow MUD policy enforcement on the local network 523 ([I-D.ietf-doh-resolver-associated-doh] and 524 [I-D.reddy-dprive-bootstrap-dns-server]). 526 5.2. Full (D)TLS 1.3 handshake inspection 528 Middle-box needs to act as a (D)TLS 1.3 proxy to observe the 529 parameters of (D)TLS handshakes from IoT devices and gain good 530 visibility into TLS 1.3 parameters. The following steps explain the 531 mechanism to automatically bootstrap IoT devices with local network's 532 CA certificates and to enable the middle-box to act as a (D)TLS 1.3 533 proxy. 535 o Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed 536 in [I-D.ietf-anima-bootstrapping-keyinfra] provides a solution for 537 secure automated bootstrap of devices. BRSKI specifies means to 538 provision credentials on devices to be used to operationally 539 access networks. In addition, BRSKI provides an automated 540 mechanism for the bootstrap distribution of CA certificates from 541 the Enrollment over Secure Transport (EST) [RFC7030] server. The 542 IoT device can use BRSKI to automatically bootstrap the IoT device 543 using the IoT manufacturer provisioned X.509 certificate, in 544 combination with a registrar provided by the local network and IoT 545 device manufacturer's authorizing service (MASA). 547 1. The IoT device authenticates to the local network using the 548 IoT manufacturer provisioned X.509 certificate. The IoT 549 device can request and get a voucher from the MASA service via 550 the registrar. The voucher is signed by the MASA service and 551 includes the local network's CA public key. 553 2. The IoT device validates the signed voucher using the 554 manufacturer installed trust anchor associated with the MASA, 555 stores the CA's public key and validates the provisional TLS 556 connection to the registrar. 558 3. The IoT device requests the full EST distribution of current 559 CA certificates (Section 5.9.1 in 560 [I-D.ietf-anima-bootstrapping-keyinfra]) from the registrar 561 operating as a BRSKI-EST server. The IoT device stores the CA 562 certificates as Explicit Trust Anchor database entries. The 563 IoT device uses the Explicit Trust Anchor database to validate 564 the server certificate. 566 4. The middle-box uses the "supported_versions" TLS extension 567 (defined in TLS 1.3 to negotiate the supported TLS versions 568 between client and server) to determine the TLS version. 569 During the (D)TLS handshake, If (D)TLS version 1.3 is used, 570 the middle-box ((D)TLS proxy) modifies the certificate 571 provided by the server and signs it with the private key from 572 the local CA certificate. The middle-box has visibility into 573 further exchanges between the IoT device and server which 574 enables it to inspect the (D)TLS 1.3 handshake, enforce the 575 MUD (D)TLS profile and can inspect subsequent network traffic. 577 5. The IoT device uses the Explicit Trust Anchor database to 578 validate the server certificate. 580 The proposed technique empowers the middle-box to reject (D)TLS 1.3 581 sessions that violate the MUD (D)TLS profile. 583 6. MUD File Example 585 This example below contains (D)TLS profile parameters for a IoT 586 device. JSON encoding of YANG modelled data [RFC7951] is used to 587 illustrate the example. 589 { 590 "ietf-mud:mud": { 591 "mud-version": 1, 592 "mud-url": "https://example.com/IoTDevice", 593 "last-update": "2019-18-06T03:56:40.105+10:00", 594 "cache-validity": 100, 595 "is-supported": true, 596 "systeminfo": "IoT device name", 597 "reddy-opsawg-mud-tls-profile:from-device-policy": { 598 "client-profile": { 599 "tls-version-profile" : [ 600 { 601 "protocol-version" : 771, 602 "supported_versions_ext" : "FALSE", 603 "encryption-algorithms" : [31354, 4865, 4866, 4867], 604 "extension-types" : [10], 605 "supported-groups" : [29], 606 "actions": { 607 "forwarding": "accept" 608 } 609 } 610 ] 611 } 612 } 613 } 614 } 616 7. Security Considerations 618 Security considerations in [RFC8520] need to be taken into 619 consideration. 621 8. IANA Considerations 623 This document requests IANA to register the following URIs in the 624 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 626 URI: urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile 627 Registrant Contact: The IESG. 628 XML: N/A; the requested URI is an XML namespace. 630 9. Acknowledgments 632 Thanks to Shashank Jain and Harsha Joshi for the discussion and 633 comments. 635 10. References 637 10.1. Normative References 639 [I-D.ietf-netconf-crypto-types] 640 Watsen, K. and H. Wang, "Common YANG Data Types for 641 Cryptography", draft-ietf-netconf-crypto-types-10 (work in 642 progress), July 2019. 644 [I-D.ietf-tls-dtls13] 645 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 646 Datagram Transport Layer Security (DTLS) Protocol Version 647 1.3", draft-ietf-tls-dtls13-32 (work in progress), July 648 2019. 650 [I-D.ietf-tls-grease] 651 Benjamin, D., "Applying GREASE to TLS Extensibility", 652 draft-ietf-tls-grease-03 (work in progress), July 2019. 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, 656 DOI 10.17487/RFC2119, March 1997, 657 . 659 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 660 DOI 10.17487/RFC3688, January 2004, 661 . 663 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 664 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 665 January 2012, . 667 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 668 RFC 6991, DOI 10.17487/RFC6991, July 2013, 669 . 671 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 672 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 673 May 2017, . 675 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 676 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 677 . 679 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 680 "YANG Data Model for Network Access Control Lists (ACLs)", 681 RFC 8519, DOI 10.17487/RFC8519, March 2019, 682 . 684 10.2. Informative References 686 [I-D.ietf-anima-bootstrapping-keyinfra] 687 Pritikin, M., Richardson, M., Behringer, M., and K. 688 Watsen, "Bootstrapping Remote Secure Key Infrastructures 689 (BRSKI)", draft-ietf-anima-bootstrapping-keyinfra-24 (work 690 in progress), July 2019. 692 [I-D.ietf-doh-resolver-associated-doh] 693 Hoffman, P., "Associating a DoH Server with a Resolver", 694 draft-ietf-doh-resolver-associated-doh-03 (work in 695 progress), March 2019. 697 [I-D.ietf-tls-sni-encryption] 698 Huitema, C. and E. Rescorla, "Issues and Requirements for 699 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-04 700 (work in progress), November 2018. 702 [I-D.reddy-dprive-bootstrap-dns-server] 703 K, R., Wing, D., Richardson, M., and M. Boucadair, "A 704 Bootstrapping Procedure to Discover and Authenticate DNS- 705 over-(D)TLS and DNS-over-HTTPS Servers", draft-reddy- 706 dprive-bootstrap-dns-server-04 (work in progress), June 707 2019. 709 [malware] Anderson, B., Paul, S., and D. McGrew, "Deciphering 710 Malware's use of TLS (without Decryption)", July 2016, 711 . 713 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 714 "Enrollment over Secure Transport", RFC 7030, 715 DOI 10.17487/RFC7030, October 2013, 716 . 718 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 719 Time Communication Use Cases and Requirements", RFC 7478, 720 DOI 10.17487/RFC7478, March 2015, 721 . 723 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 724 RFC 7951, DOI 10.17487/RFC7951, August 2016, 725 . 727 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 728 Connectivity Establishment (ICE): A Protocol for Network 729 Address Translator (NAT) Traversal", RFC 8445, 730 DOI 10.17487/RFC8445, July 2018, 731 . 733 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 734 Description Specification", RFC 8520, 735 DOI 10.17487/RFC8520, March 2019, 736 . 738 Authors' Addresses 740 Tirumaleswar Reddy 741 McAfee, Inc. 742 Embassy Golf Link Business Park 743 Bangalore, Karnataka 560071 744 India 746 Email: kondtir@gmail.com 748 Dan Wing 749 Citrix Systems, Inc. 750 4988 Great America Pkwy 751 Santa Clara, CA 95054 752 USA 754 Email: danwing@gmail.com