idnits 2.17.1 draft-rafiee-dnssd-mdns-threatmodel-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 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 (October 27, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 427, 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 4 Intended Status: Informational 5 Expires: April 27, 2015 October 27, 2014 7 Multicast DNS (mDNS) Threat Model and Security Consideration 8 10 Abstract 12 This document describes threats associated with 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 April 27, 2015. 32 Copyright Notice 34 Copyright (c) 2014 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. DoS attack on any node in the DNS-SD enabled network . . 4 51 3.1.1. Personal Area Network (PAN) . . . . . . . . . . . . . 4 52 3.1.2. Temporary Public Hotspot . . . . . . . . . . . . . . 5 53 3.2. Node compromising . . . . . . . . . . . . . . . . . . . 5 54 3.2.1. Home, Enterprise, Mesh networks . . . . . . . . . . . 5 55 3.3. Spoofing Attacks & forge the Identity . . . . . . . . . . 5 56 3.3.1. Public Hotspot, Home, Enterprise, Mesh networks . . . 5 57 3.3.2. Enterprise network . . . . . . . . . . . . . . . . . 5 58 3.4. Malicious update on unicast DNS . . . . . . . . . . . . . 5 59 3.5. Cache Poisoning . . . . . . . . . . . . . . . . . . . . 6 60 3.6. Harming Privacy . . . . . . . . . . . . . . . . . . . . . 6 61 3.7. Resource spoofing . . . . . . . . . . . . . . . . . . . . 6 62 3.8. Dual stack attacks . . . . . . . . . . . . . . . . . . . 6 63 3.9. MAC address spoofing . . . . . . . . . . . . . . . . . . 6 64 3.10. Privacy Protection Mechanisms . . . . . . . . . . . . . 6 65 3.10.1. The Use of Random Data . . . . . . . . . . . . . . . 6 66 3.10.2. Data Encryption . . . . . . . . . . . . . . . . . . 7 67 3.11. Authorization of a Service Requester . . . . . . . . . . 7 68 3.11.1. The Use of an Access List . . . . . . . . . . . . . 7 69 3.11.1.1. SAVI-DHCP . . . . . . . . . . . . . . . . . . . 7 70 3.11.1.2. CGA-TSIG . . . . . . . . . . . . . . . . . . . . 7 71 3.11.1.3. DNS over DTLS . . . . . . . . . . . . . . . . . 8 72 3.11.2. The Use of Shared Secret . . . . . . . . . . . . . . 8 73 3.12. Authorization of a Service Provider . . . . . . . . . . 8 74 3.12.1. SAVI-DHCP . . . . . . . . . . . . . . . . . . . . . 8 75 3.12.2. Router advertisement . . . . . . . . . . . . . . . . 8 76 3.13. Other Security Considerations . . . . . . . . . . . . . 8 77 3.14. Not Usable Security Mechanisms . . . . . . . . . . . . 9 78 3.14.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 9 79 3.14.2. IPsec . . . . . . . . . . . . . . . . . . . . . . . 9 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 9 85 7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 Multicast DNS (mDNS) was proposed in [RFC6762] to allow nodes in 91 local links to use DNS-like names for their communication without the 92 need for global DNS servers, infrastructure and administration 93 processes for configuration. mDNS along with service discovery 94 (DNS-SD) [RFC6763] provides nodes with the possibility to discover 95 other services and the names of other nodes with zero configuration, 96 i.e., connect a node into a local link and use resources such as a 97 printer that are available in that network. 99 mDNS and service discovery (SD) use DNS- like query messages. The 100 main assumption is that these services also use DNS security 101 protocols such as DNSSEC. However, it cannot use DNSSEC for security 102 because DNSSEC is not zero configuration service. This is why the 103 current implementations use no security in local links and are 104 vulnerable to several attacks. 106 The purpose of this document is to introduce threat models for 107 service discovery and allow implementers to be aware of the possible 108 attacks in order to mitigate them with possible solutions. Since 109 there are already old lists of known DNS threats available in 110 [RFC3833], here we only analyze the ones that are applicable to 111 DNS-SD. We also introduce new possible threats that could result from 112 extending DNS-SD scope. 114 2. Terminology 116 Node: any host and routers in the network 118 Attack: an action to exploit a node and allow the attacker to gain 119 access to that node. It can be also an action to prevent a node from 120 providing a service or using a service on the network 122 Attacker: a person who uses any node in the network to attack other 123 nodes using known or unknown threats 125 Threat: Anything that has a potential to harm a node in the network 127 Local link vulnerability: Any flaws that are the result of the 128 assumption that a malicious node could gain access to legitimate 129 nodes inside a local link network 131 Wide Area Network (WAN) vulnerability: Any flaws that are the result 132 of the assumption that a malicious node could gain access to 133 legitimate nodes inside any local links in an enterprise network with 134 multiple Local Area Networks (LANs) or Virtual LANs (VLANs). 136 Host name: Fully qualified DNS Name (FQDN) of a node in the network 138 Constrained device: a small device with limited resources (battery, 139 memory, etc.) 141 Service Providers: a node that offer a service to other nodes. One 142 example of a service provider in DNS-SD is a printer. 144 Service Requester: a node in the network that requests a service by 145 the use of DNS-SD protocols. One example of service requester is a 146 computer that discovers a printer in the network and tries to use it. 148 3. Threat Analysis 150 DNS-SD cannot use DNSSEC approaches for security purposes. This is 151 because, as mentioned earlier, DNSSEC is not a zero config protocol 152 and it is not compatible with the plug and play nature of DNS-SD. 153 This is why DNS-SD is vulnerable to several attacks. Most threats in 154 this section are a result of spoofing, Denial of Service (DoS), or a 155 combination of them. Here we explain them in different example 156 scenarios. The definition of different use case scenarios are defined 157 in [requirement]. 159 There are several scenarios associated with the Large Traffic 160 Production case. 162 First scenario: a malicious node in any of the subnets that the 163 gateway connects can advertise different fake services or spoof the 164 information of the real services and replay the messages. This causes 165 large traffic either in the local link or in other links since the 166 gateway was also supposed to replicate the traffic to other links. 168 Second scenario : a malicious node spoofs the legitimate service 169 advertisements of different nodes in the network and changes the Time 170 To Leave (TTL) value to zero. This will result in producing large 171 traffic since the mDNS gateway needs to ask all of the service 172 advertisers to re-advertise their service. This is an especially 173 effective attack in a network of constrained devices because it 174 causes more energy consumption. 176 3.1. DoS attack on any node in the DNS-SD enabled network 178 3.1.1. Personal Area Network (PAN) 180 When service provider and service requester are connected via a 181 network cable or USB, then the only threat is virus or other malware 182 that might infect any of these nodes. This might cause DoS. 184 Wireless PAN (WPAN) is where service provider and service requester 185 are connected via Bluetooth or wireless. Since WPANs are short range 186 and their coverage are usually limited, the attacker should be so 187 close to any of those nodes to be able to perform any attacks. If 188 this happens, the attacker might be able to forge the identity of the 189 service provider or perform DoS attack. 191 3.1.2. Temporary Public Hotspot 193 A malicious node can spoof the source IP address of a legitimate 194 victim node and question several services in the link. This will 195 result in a large traffic return to the victim node from both gateway 196 and also service owner. 198 3.2. Node compromising 200 3.2.1. Home, Enterprise, Mesh networks 202 When ISP, home router/gateway and service provider (like a printer) 203 support IPv6 address, then service providers usually automatically 204 sets an IPv6 address. Since this address is global, this node is 205 accessible over the internet. If the address of this service provider 206 is known to the attacker, then it might be able to compromise this 207 service provider and access to this network (because service 208 providers usually supports weak security features). 210 3.3. Spoofing Attacks & forge the Identity 212 3.3.1. Public Hotspot, Home, Enterprise, Mesh networks 214 Scenario 1: A malicious node can spoof the source IP address of a 215 legitimate victim node advertises fake services in the network. This 216 might result in compromising the victim nodes or having malicious 217 access to the victim nodes' resources. 219 Scenario2: A malicious node spoofs the content of Dynamic Host 220 Configuration Protocol (DHCP) server messages and offers its own 221 malicious information to the nodes in the network. 223 3.3.2. Enterprise network 225 A virus or any malware can compromise a legitimate node in this 226 network. Then this node can forge the identity of service providers 227 or perform DoS attack on this network. 229 3.4. Malicious update on unicast DNS 231 A malicious node can spoof the content of DNS update message and add 232 malicious records to unicast DNS. This attack is applicable on 233 enterprise networks. 235 3.5. Cache Poisoning 237 Usually a list of service providers is cached in the service 238 requester. When a malicious node has a chance to compromise this 239 cache by advertising fake services, then the service requester might 240 always connect to this fake service provider. This attack is 241 applicable to temporary public hotspot, home, enterprise, Mesh and 242 6LowPAN networks. 244 3.6. Harming Privacy 246 If a malicious node is in any subnet (WLAN and WAN) of a network, it 247 can learn about all services available in this network. The DNS-SD 248 discloses some critical information about resources in this network 249 which might be harmful to privacy. This attack is applicable to 250 temporary public hotspot and enterprise networks. 252 3.7. Resource spoofing 254 Resource owners in the network have permission to have the same name 255 for load balancing. A malicious node can claim to be one of the load 256 balanced resource devices and maliciously respond to requests. This 257 is applicable to temporary public hotspot and enterprise networks. 259 3.8. Dual stack attacks 261 Having both IPv4 and IPv6 in the same network and trying to aggregate 262 service discovery traffic on both IP stacks might cause new security 263 flaws during the conversion or aggregation of this traffic. It can be 264 similar to what explained here as an aggregated traffic or lead to a 265 wide range of spoofing attacks. This attack is applicable to home, 266 enterprise and temporary public hotspots. 268 3.9. MAC address spoofing 270 In a wireless environment where MAC address filtering is in use to 271 avoid any malicious node joining to the network, a malicious node can 272 easily spoof the MAC address of a legitimate node and join the 273 network and perform malicious activities. This attack is applicable 274 to temporary public networks and enterprise networks. 276 3.10. Privacy Protection Mechanisms 278 3.10.1. The Use of Random Data 280 Using a random name for services or devices or the use of random 281 numbers wherever possible, might prevent exposing the exact model or 282 exact information regarding the DNS-SD service providers (e.g. 283 printers, etc.) in the network to the attackers. However, this 284 approach cannot be used for some standard information that the 285 protocol needs to carry in order to offer service to other nodes. 286 Otherwise, this random information was exchanged and agreed on 287 between service providers and service requesters beforehand. This is 288 exactly against the nature of zero conf protocols, i.e., DNS-SD 290 3.10.2. Data Encryption 292 Encrypting the whole DNS-SD message is another way to hide the 293 critical information in the network. But this approach might not fit 294 well to the nature of this protocol. The reason is because these 295 devices usually respond to anonymous service discovery requests. So, 296 the attacker can also submit and request the same information. In 297 other words, encryption in this stage is only extra efforts without 298 having any benefit from it. 300 3.11. Authorization of a Service Requester 302 3.11.1. The Use of an Access List 304 There can be an access list on each service providers with the list 305 of IP addresses that can use these services. Then the service 306 providers can use mechanisms to authorize the service requesters or 307 to securely authenticate them with minimum interaction (zero 308 configuration). This approach prevents the service providers from 309 unauthorized use by an attacker. There are currently some mechanisms 310 available -- SAVI-DHCP, CGA-TSIG, etc. 312 3.11.1.1. SAVI-DHCP 314 SAVI-DHCP [DHCP-SAVI] approach uses a simple mechanism in switches or 315 devices that knows information about the ports of switches to filter 316 any malicious traffic. This mitigates attacks on DHCP server spoofing 317 and can make sure that nobody can spoof the IP address of the service 318 providers. 320 3.11.1.2. CGA-TSIG 322 CGA-TSIG [cga-tsig] is another possible solution that can provide the 323 node with secure authentication, data integrity and data 324 confidentiality. It provides the node with zero or minimal 325 configuration and prevents IP spoofing. This is useful when the node 326 needs to update any record on an unicast DNS or there is an access 327 list on service providers. This approach can be used to authenticate 328 and authorize a node to use a service or a device. 330 3.11.1.3. DNS over DTLS 332 3.11.2. The Use of Shared Secret 334 A shared secret (e.g. a password) can be shared among the service 335 requesters. Then this value can be used to access the service 336 providers and authenticated on them. However, this approach has a 337 disadvantage when one of the nodes in this network that carries this 338 shared secret is compromised then the attacker can also have 339 unauthorized access to these services. Sharing and re-sharing this 340 shared secret does not fit to the zero conf nature of DNS-SD 341 protocol. 343 3.12. Authorization of a Service Provider 345 It is really important for the service requesters to ensure that the 346 one claim to be a service provider (e.g. a printer) is really a 347 service provider and its identity has not been forged by the 348 attacker. The service requester needs to receive the IP address of 349 service providers in a secure manner. There are some approaches that 350 can be used for this purpose such as SAVI-DHCP, Router Advertisement. 351 There are also some mechanisms that can be used in service requesters 352 to complete this authentication and authorization processes such as 353 CGA-TSIG, DNS over TLS 355 3.12.1. SAVI-DHCP 357 The DHCP server can carry this information and send it to the service 358 requesters at the same time as the service requesters receive a new 359 IP address from the DHCP servers. 361 3.12.2. Router advertisement 363 If Neighbor Discovery Protocol (NDP) [RFC4861] or Secure Neighbor 364 Discovery (SeND) [RFC3971] are in use, then an option can be added to 365 a router advertisement message which carries required information 366 regarding the IP addresses of service providers. This is especially 367 secure when SeND is in use. 369 3.13. Other Security Considerations 371 Since a WLAN might also cover a part of city, it is really important 372 to make sure that there is required filtering in edge networks to 373 avoid distribution of mDNS/DNS-SD messages beyond the enterprise 374 networks. 376 3.14. Not Usable Security Mechanisms 378 There are some other security mechanisms that are not fit to the zero 379 conf nature of DNS-SD protocol but might be useable in future. 381 3.14.1. DNSSEC 383 Due to the pre-configuration required for DNSSEC on each nodes and 384 DNS servers, it is not an ideal solution mechanism for zero config 385 services. It might also necessary to access to internet to verify the 386 DNSSEC keys and prevent IP spoofing (ask the trusted anchors the 387 validity of the DNSSEC keys) 389 3.14.2. IPsec 391 IPsec is another security protection mechanism. Similar to DNSSEC, it 392 requires manual step for the configuration of the nodes. However, 393 recently there are some new drafts to automate this process. This is, 394 of course, might not be an ideal solution for DNS-SD. This is because 395 as explained in section 4.1.2 encryption of the whole message might 396 not be really helpful since the attacker can also request the same 397 service. 399 4. Security Considerations 401 This document documents the security of mDNS and DNS-SD. It does not 402 introduce any additional security considerations 404 5. IANA Considerations 406 There is no IANA consideration 408 6. Acknowledgements 410 The author would like to thank all those people who directly helped 411 in improving this draft, especially John C. Klensin, Douglas Otis and 412 Dan York 414 7. References 416 7.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to 419 Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 421 [RFC6762] Cheshire, S., Krochmal, M.,"Multicast DNS", RFC 422 6762, February 2013 424 [RFC6763] Cheshire, S., Krochmal, M., "DNS-Based Service 425 Discovery", RFC 6763, February 2013 427 [RFC6275] Perkins, C., Johnson, D., Arkko, J., "Mobility 428 Support in IPv6", RFC 6275, July 2011 430 [RFC3833] Atkins, D., Austein, R., "Threat Analysis of the 431 Domain Name System (DNS)", RFC 3833, August 2004 433 [RFC3971] Arkko, J., Kempf, J., Zill, B., and Nikander, P., 434 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 436 [RFC4861] Narten, T., Nordmark, E., Simpson, W., Soliman, 437 H., "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 438 September 2007. 440 7.2. Informative References 442 [requirement] Lynn, K., Cheshire, S., Blanchet, M., 443 Migault, D., " Requirements for Scalable DNS-SD/mDNS 444 Extensions", 445 http://tools.ietf.org/html/draft-ietf-dnssd-requirements-04, 446 October 2014 448 [DHCP-SAVI] Bi, J., Wu, J., Yao, G, Baker, F.,"SAVI 449 Solution for DHCP", 450 http://tools.ietf.org/html/draft-ietf-savi-dhcp-23, April 451 2014 453 [cga-tsig] Rafiee, H., Loewis, M., Meinel, C.,"Transaction 454 SIGnature (TSIG) using CGA Algorithm in IPv6", 455 http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig , 456 June 2014 458 Authors' Addresses 460 Hosnieh Rafiee 461 HUAWEI TECHNOLOGIES Duesseldorf GmbH 462 Riesstrasse 25, 80992 463 Munich, Germany 464 Phone: +49 (0)162 204 74 58 465 Email: ietf@rozanak.com