idnits 2.17.1 draft-rafiee-dnssd-mdns-threatmodel-03.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 is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 30, 2015) is 3254 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 444, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSSD H. Rafiee 3 INTERNET-DRAFT Rozanak 4 Intended Status: Informational 5 Expires: November 30, 2015 May 30, 2015 7 Multicast DNS (mDNS) Threat Model and Security Consideration 8 10 Abstract 12 This document describes threats only specific to extending multicast 13 DNS (mDNS) across layer 3. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute working 22 documents as Internet-Drafts. The list of current Internet-Drafts is 23 at http://datatracker.ietf.org/drafts/current. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on November 30, 2015. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. This document is subject to 36 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 37 Documents (http://trustee.ietf.org/license-info) in effect on the 38 date of publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with respect 40 to this document. Code Components extracted from this document must 41 include Simplified BSD License text as described in Section 4.e of 42 the Trust Legal Provisions and are provided without warranty as 43 described in the Simplified BSD License. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 4 50 3.1. Human Mistakes . . . . . . . . . . . . . . . . . . . . . 4 51 3.2. DoS attack . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.2.1. Large Traffic from mDNS gateway . . . . . . . . . . . 4 53 3.2.2. Single point of failure . . . . . . . . . . . . . . . 5 54 3.3. IPv6 specific mDNS scope problems . . . . . . . . . . . . 5 55 3.4. Malicious update on unicast DNS . . . . . . . . . . . . . 5 56 3.4.1. mixing unicast names with mDNS names . . . . . . . . 5 57 3.5. Privacy Problems . . . . . . . . . . . . . . . . . . . . 6 58 3.5.1. Storing mDNS names in unicast DNS . . . . . . . . . . 6 59 3.6. Internationalized label and Rogue service . . . . . . . . 6 60 3.7. Dual stack attacks . . . . . . . . . . . . . . . . . . . 6 61 3.8. Privacy Protection Mechanisms . . . . . . . . . . . . . . 6 62 3.8.1. The Use of Random Data . . . . . . . . . . . . . . . 6 63 3.8.2. Data Encryption . . . . . . . . . . . . . . . . . . . 7 64 3.9. Evaluation of Security Protection Mechanisms . . . . . . 7 65 3.9.1. Unicast DNS protection mechanisms . . . . . . . . . . 7 66 3.9.1.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . 7 67 3.9.1.2. CGA-TSIG . . . . . . . . . . . . . . . . . . . . 7 68 3.9.1.3. DNS over DTLS . . . . . . . . . . . . . . . . . . 7 69 3.9.2. Authorization of a Service Requester . . . . . . . . 7 70 3.9.2.1. The Use of an Access List . . . . . . . . . . . . 7 71 3.9.2.2. SAVI-DHCP . . . . . . . . . . . . . . . . . . . . 8 72 3.9.2.3. The Use of Shared Secret . . . . . . . . . . . . 8 73 3.9.3. Authorization of a Service . . . . . . . . . . . . . 8 74 3.9.3.1. SAVI-DHCP . . . . . . . . . . . . . . . . . . . 8 75 3.9.3.2. Router advertisement . . . . . . . . . . . . . . 8 76 3.9.4. ULA and GUA Considerations . . . . . . . . . . . . . 9 77 3.9.4.1. mDNS proxy and Security consideration . . . . . . 9 78 3.9.5. Other Security Considerations . . . . . . . . . . . . 9 79 3.10. Not Usable Security Mechanisms . . . . . . . . . . . . 9 80 3.10.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . 9 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 10 86 7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 11 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 Multicast DNS (mDNS) was proposed in [RFC6762] to allow nodes in 92 local links to use DNS-like names for their communication without the 93 need for global DNS servers, infrastructure and administration 94 processes for configuration. mDNS along with service discovery 95 (DNS-SD) [RFC6763] provides nodes with the possibility to discover 96 other services and the names of other nodes with zero configuration, 97 i.e., connect a node into a local link and use resources such as a 98 printer that are available in that network. 100 mDNS and service discovery (SD) use DNS- like query messages. The 101 main assumption is that these services also use DNS security 102 protocols such as DNSSEC. However, it cannot use DNSSEC for security 103 because DNSSEC is not zero configuration service. Therefore, it 104 cannot be used for Requirements A, B,C in [requirement]. Besides, 105 DNSSEC cannot be implemented in all nodes, especially nodes with 106 limited resources, e.g. 6LoWPAN [RFC4944]. This is why the existing 107 implementations use no security in local links. This might be not a 108 critical problem when the service was only advertised in local link 109 but it is not the same when the service is going to be advertised 110 over layer 3 and in larger scope. Furthermore, during this step, 111 DNS-SD did not consider the impact of [RFC4193] that should be 112 carefully considered when using mDNS to populate DNS. As such, a 113 Universal Local Address (ULA) prefix is not to be advertised outside 114 the network domain. This is also similar to the scenario where 115 address preference rules employed by a proxy device as defined in 116 section 2.4. [RFC7368]. 118 The purpose of this document is to introduce threat models for 119 service discovery and allow implementers to be aware of the possible 120 attacks in order to mitigate them with possible solutions. Since 121 there are already old lists of known DNS threats available in 122 [RFC3833], here we only analyze the ones that are applicable to 123 DNS-SD. We also introduce new possible threats that could result from 124 extending DNS-SD scope. 126 2. Terminology 128 Node: any host and routers in the network 130 Attack: an action to exploit a node and allow the attacker to gain 131 access to that node. It can be also an action to prevent a node from 132 providing a service or using a service on the network 134 Attacker: a person who uses any node in the network to attack other 135 nodes using known or unknown threats 137 Threat: Anything that has a potential to harm a node in the network 139 Local link vulnerability: Any flaws that are the result of the 140 assumption that a malicious node could gain access to legitimate 141 nodes inside a local link network 143 Wide Area Network (WAN) vulnerability: Any flaws that are the result 144 of the assumption that a malicious node could gain access to 145 legitimate nodes inside any local links in an enterprise network with 146 multiple Local Area Networks (LANs) or Virtual LANs (VLANs). 148 Host name: Fully qualified DNS Name (FQDN) of a node in the network 150 Constrained device: a small device with limited resources (battery, 151 memory, etc.) 153 Service advertiser or service: a node that has a service to 154 advertise, e.g. a printer 156 Service Requester: a node in the network that requests a service by 157 the use of DNS-SD protocols. One example of service requester is a 158 computer that discovers a printer in the network and tries to use it. 160 3. Threat Analysis 162 This section only focuses on threats that are specific to 163 mDNS/DNS-SD. Here we explain them in different example scenarios. The 164 definition of different use case scenarios are defined in 165 [requirement]. 167 3.1. Human Mistakes 169 For those deployments that needs configuration, mis-configuration of 170 DNS-SD scope on edge devices such as a router or a gateway might 171 allow an attacker to gain access to services or expose the network 172 topology to outside of an administrative domains. This is applicable 173 to all scenarios including PAN, WPAN, home, enterprise, campus, mesh 174 networks. 176 3.2. DoS attack 178 3.2.1. Large Traffic from mDNS gateway 180 There are several scenarios associated with the Large Traffic 181 Production case. 183 First scenario: a malicious node in any of the subnets that the 184 gateway connects can advertise different fake services or spoof the 185 information of the real services and replay the messages. This causes 186 large traffic either in the local link or in other links since the 187 gateway was also supposed to replicate the traffic to other links. 189 Second scenario : a malicious node spoofs the legitimate service 190 advertisements of different nodes in the network and changes the Time 191 To Live (TTL) value to zero. This will result in producing large 192 traffic since the mDNS gateway needs to ask all of the service 193 advertisers to re-advertise their service. This is an especially 194 effective attack in a network of constrained devices because it 195 causes more energy consumption. 197 Third scenario: a malicious node can spoof the source IP address of a 198 legitimate victim node and question several services in the link. 199 This will result in a large traffic return to the victim node from 200 both gateway and also services. 202 3.2.2. Single point of failure 204 a service (like a printer) can overwhelmed with many service 205 discovery requests from a malicious service requester. This might 206 result in long waiting times (delay) for a legitimate node to receive 207 a service. 209 3.3. IPv6 specific mDNS scope problems 211 When the ISP, home router/gateway, and a service (like a printer) 212 support IPv6 addressing, these services may automatically announce 213 over mDNS both Unique Local Addresses (ULA) [RFC4193] and Global 214 Unicast Addresses (GUA). Since a GUA is accessible over the internet, 215 the associated node may become available to the public. The 216 advertisement needs to be under control to avoid a GUA for a service 217 becomes known to an attacker. Furthermore, the ULA scope should be 218 clearly defined so that it does not advertise it to unwanted scope. 219 This is because it might grant unintended access to a service 220 otherwise limited by boundaries imposed by mDNS discovery. This 221 attack is applicable to home, public hotspot, enterprise, campus and 222 mesh networks. 224 3.4. Malicious update on unicast DNS 226 A malicious node can spoof the content of DNS update message and add 227 malicious records to unicast DNS. This attack is applicable on 228 enterprise networks. 230 3.4.1. mixing unicast names with mDNS names 232 A fake service might poison the cache of a service requester with 233 records that has global unicast name, if the service requester's 234 deployment needs configuration and is poorly configured or the 235 implementation has problem, then the mDNS request might have priority 236 over DNS request which will lead to phishing attacks. 238 3.5. Privacy Problems 240 If a malicious node is in any subnet (WLAN and WAN) of a network, it 241 can learn about all services available in this network. The DNS-SD 242 discloses some critical information about resources in this network 243 which might be harmful to privacy. This attack is applicable to 244 temporary public hotspot and enterprise networks. 246 3.5.1. Storing mDNS names in unicast DNS 248 When a name of a service is stored in unicast DNS Resource Records, 249 in case this unicast DNS is accessible over the internet or over 250 several networks, it might expose the services to unwanted nodes and 251 harms privacy. This is applicable to campus networks, mesh networks, 252 temporary public hotspots and enterprise networks. 254 3.6. Internationalized label and Rogue service 256 Using Internationalized label might allow an attacker to advertise a 257 fake service with similar looking character as legitimate service. 258 This might lead to the case where user chooses fake advertised 259 service as a legitimate one. 261 3.7. Dual stack attacks 263 Having both IPv4 and IPv6 in the same network and trying to aggregate 264 service discovery traffic on both IP stacks might cause new security 265 flaws during the translation or aggregation of this traffic. It might 266 lead to wide range of spoofing attacks or leak service advertisements 267 (the service advertisement is no longer under control). This attack 268 is applicable to home, enterprise, campus, mesh and temporary public 269 hotspots. 271 3.8. Privacy Protection Mechanisms 273 3.8.1. The Use of Random Data 275 Using a random name for services or devices or the use of random 276 numbers wherever possible, might prevent exposing the exact model or 277 exact information regarding the DNS-SD service providers (e.g. 278 printers, etc.) in the network to the attackers. However, this 279 approach cannot be used for some standard information that the 280 protocol needs to carry in order to offer service to other nodes. 281 Otherwise, this random information was exchanged and agreed on 282 between service providers and service requesters beforehand. This is 283 exactly against the nature of zero conf protocols, i.e., DNS-SD 285 3.8.2. Data Encryption 287 Encrypting the whole DNS-SD message is another way to hide the 288 critical information in the network. But this approach might not fit 289 well to the nature of this protocol. The reason is because these 290 devices usually respond to anonymous service discovery requests. So, 291 the attacker can also submit and request the same information. In 292 other words, encryption in this stage is only extra efforts without 293 having any benefit from it. 295 3.9. Evaluation of Security Protection Mechanisms 297 3.9.1. Unicast DNS protection mechanisms 299 3.9.1.1. DNSSEC 301 DNSSEC can be used to allow any services to update its records on 302 unicast DNS that supports DNSSEC. However, it is not a zero 303 configuration mechanism and need the introduction of the DNSSEC key 304 to a service or availability of a trust model. Furthermore, this 305 mechanism does not provide data confidentiality. 307 3.9.1.2. CGA-TSIG 309 CGA-TSIG [cga-tsig] is another possible solution that can provide the 310 node with secure authentication, data integrity and data 311 confidentiality. It provides the node with zero or minimal 312 configuration when it is integrated with SAVI-DHCP or secure RA 313 message [RFC7113]. This is useful when the node needs to update any 314 record on an unicast DNS or there is an access list on services. This 315 approach can be used to authenticate and authorize a node to use a 316 service or a device. 318 3.9.1.3. DNS over DTLS 320 3.9.2. Authorization of a Service Requester 322 3.9.2.1. The Use of an Access List 324 There can be an access list on each service with the list of IP 325 addresses that can use these services. Then the service can use 326 mechanisms to authorize the service requester or to securely 327 authenticate them with minimum interaction (zero configuration). This 328 approach prevents the service from unauthorized use by an attacker. 329 There are currently some mechanisms available -- SAVI-DHCP, CGA-TSIG, 330 etc. 332 3.9.2.2. SAVI-DHCP 334 SAVI-DHCP [DHCP-SAVI] approach uses a simple mechanism in switches or 335 devices that knows information about the ports of switches to filter 336 any malicious traffic. This mitigates attacks on DHCP server spoofing 337 and can make sure that nobody can spoof the IP address of the service 338 providers. 340 3.9.2.3. The Use of Shared Secret 342 A shared secret (e.g. a password) can be shared among the service 343 requesters. Then this value can be used to access the services and 344 authenticated to them. However, this approach has a disadvantage. 345 This is because when one of the nodes in this network that carries 346 this shared secret is compromised then the attacker can also have 347 unauthorized access to these services. Sharing and re-sharing this 348 shared secret does not fit to the zero conf nature of DNS-SD 349 protocol. 351 3.9.3. Authorization of a Service 353 It is really important for the service requesters to ensure that the 354 one claim to be a service (e.g. a printer) is really a service and 355 its identity has not been forged by the attacker. The service 356 requester needs to receive the IP address of services in a secure 357 manner. There are some approaches that can be used for this purpose 358 such as SAVI-DHCP, Router Advertisement. There are also some 359 mechanisms that can be used in service requesters to complete this 360 authentication and authorization processes such as CGA-TSIG, DNS over 361 TLS 363 3.9.3.1. SAVI-DHCP 365 The DHCP server can carry this information and send it to the service 366 requesters at the same time as the service requesters receive a new 367 IP address from the DHCP servers. 369 3.9.3.2. Router advertisement 371 If Neighbor Discovery Protocol (NDP) [RFC4861] or Secure Neighbor 372 Discovery (SeND) [RFC3971] are in use, then an option can be added to 373 a router advertisement message which carries required information 374 regarding the IP addresses of services. This is especially secure 375 when SeND is in use. There can be also other protection mechanisms 376 that is explained in [RFC7113]. 378 3.9.4. ULA and GUA Considerations 380 As explained earlier, a ULA prefix is not to be advertised outside 381 the network domain. Administrators need to clearly set the scope of 382 the ULAs and configure ACLs on relevant border routers to enforce 383 this scope. If internal DNS is used, administrators should use 384 internal-only DNS names for ULAs and perhaps use split horizon DNS to 385 ensure internal names do not resolve on the Internet as described in 386 RFC6950. 388 3.9.4.1. mDNS proxy and Security consideration 390 Unlike IPv4, there can be multiple IP address assignments per 391 interface. For example, a printer might return both GUA and ULA. From 392 a security standpoint, it becomes essential only ULAs be published in 393 DNS-SD populated by mDNS. 395 3.9.5. Other Security Considerations 397 Since a WLAN might also cover a part of city, it is really important 398 to make sure that there is required filtering in edge networks to 399 avoid distribution of mDNS/DNS-SD messages beyond the enterprise 400 networks. 402 3.10. Not Usable Security Mechanisms 404 There are some other security mechanisms that are not fit to DNS-SD 405 protocol but might be useable in future. 407 3.10.1. IPsec 409 IPsec is a security protection mechanism. It requires manual step for 410 the configuration of the nodes. However, recently there are some new 411 drafts to automate this process. This is, of course, might not be an 412 ideal solution for DNS-SD. It is because it might not fit to nodes 413 with limited resources (e.g. battery). Data encryption, as explained 414 in section 3.12.2. is not suitable for DNS-SD. 416 4. Security Considerations 418 This document documents the security of mDNS and DNS-SD. It does not 419 introduce any additional security considerations 421 5. IANA Considerations 423 There is no IANA consideration 425 6. Acknowledgements 427 The author would like to thank all those people who directly helped 428 in improving this draft, especially John C. Klensin, Douglas Otis, 429 Dan York and Harald Albrecht 431 7. References 433 7.1. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to 436 Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC6762] Cheshire, S., Krochmal, M.,"Multicast DNS", RFC 439 6762, February 2013 441 [RFC6763] Cheshire, S., Krochmal, M., "DNS-Based Service 442 Discovery", RFC 6763, February 2013 444 [RFC6275] Perkins, C., Johnson, D., Arkko, J., "Mobility 445 Support in IPv6", RFC 6275, July 2011 447 [RFC3833] Atkins, D., Austein, R., "Threat Analysis of the 448 Domain Name System (DNS)", RFC 3833, August 2004 450 [RFC3971] Arkko, J., Kempf, J., Zill, B., and Nikander, P., 451 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 453 [RFC4861] Narten, T., Nordmark, E., Simpson, W., Soliman, 454 H., "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 455 September 2007. 457 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., Culler, 458 D., "Transmission of IPv6 Packets over IEEE 802.15.4 459 Networks", RFC 4944, September 2007. 461 [RFC7113] Gont, F.,"Implementation Advice for IPv6 Router 462 Advertisement Guard (RA-Guard)", RFC 7113, February 2014. 464 [RFC4193] Hinden, R., Haberman, B., "Unique Local IPv6 465 Unicast Addresses", RFC 4193, October 2005 467 [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., 468 Weil, J., "Unique Local IPv6 Unicast Addresses", RFC 7368, 469 October 2014 471 7.2. Informative References 473 [requirement] Lynn, K., Cheshire, S., Blanchet, M., 474 Migault, D., " Requirements for Scalable DNS-SD/mDNS 475 Extensions", 476 http://tools.ietf.org/html/draft-ietf-dnssd-requirements-06, 477 March 2015 479 [DHCP-SAVI] Bi, J., Wu, J., Yao, G, Baker, F.,"SAVI 480 Solution for DHCP", 481 http://tools.ietf.org/html/draft-ietf-savi-dhcp-34, 482 February 2015 484 [cga-tsig] Rafiee, H., Loewis, M., Meinel, C.,"Transaction 485 SIGnature (TSIG) using CGA Algorithm in IPv6", 486 http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig , 487 June 2014 489 Authors' Addresses 491 Hosnieh Rafiee 492 http://www.rozanak.com 493 Munich, Germany 494 Phone: +49 (0)176 57587575 495 Email: ietf@rozanak.com