Subject: [dnssd] draft-ietf-dnssd-requirements-00.txt: Requirements/Security Considerations

From: Daniel Migault <[email-masked]>
Date: Sun, 19 Jan 2014 09:16:33 +0100

Hi Folks,

Here are some additional requirements for
draft-ietf-dnssd-requirements-00.txt as well as a starting point for
the security consideration section. This section has been updated with
Tim's comments.

Your are more than welcome to comment/clarify/change the proposed
text. We would appreciate you provide them by Friday January 23 so
they can be considered for the next version.

Best Regards,

Daniel

** Terminology section:

I think we should add the following terms. I am using used them in the
remaining of the mail. They may be changed for the draft.

mDNS: multicast DNS as defined in [RFC6762]
SSD: Scalable Service Discovery
SD DNS-Based Service Discovery [RFC6763]

** Requirements section:

I suggest adding or complete existing requirements with the following ones:

SSD SHOULD be designed for both DNS and mDNS working in a cooperative
way. More specifically, it SHOULD consider interaction between DNS and
mDNS.

SSD SHOULD be able to be performed by client only using DNS and
unicast to avoid multiple multicast messages.

SSD SHOULD work with existing DNS-Based Service Discovery over mDNS
and SHOULD NOT break any other discovery protocols.
As specified in the charter [http://datatracker.ietf.org/wg/dnssd/charter/]
"The WG will consider the tradeoffs between reusing/extending existing
protocols and developing entirely new ones. It is highly desirable
that any new solution is backwardly compatible with existing DNS-SD/mDNS
deployments. Any solution developed by the dnssd WG must not conflict
or interfere with the operation of other zero-configuration service and
naming protocols such as uPnP or LLMNR. Integration with such protocols
is out of scope for this WG."

and

"To document challenges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace."

SSD SHOULD consider the use of globally unique FQDN that is specific
of a given network instead of a default domain name as ".local". SSD
SHOULD provide means to discover/announce the FQDN associated to the
network. A default and common FQDN - like ".local." could be used only
when the specific FQDN of the network has not been determined.
Furthermore, in order to ease interoperation with DNS the domain name
SHOULD follow DNS-compatible encoding (i.e ascii or punycode).

SSD SHOULD be able to take advantage of network configurations
(DHCP/RA) protocol. If it is clear that SSD and DNS SHOULD be able to
work together, DHCP may also be used to announce necessary information
for the network such as its associated FQDN (using DHCP Domain Search
/ DHCP Domain option / IPv6 RA [RFC6106]), the interface to register
FQDNs... This MAY for example complement or avoid the use of the
specific b/db/r/dr/lb.dns-sd._udp.<domain> or equivalent queries.

SSD SHOULD be able to announce the scope Service Discovery
informations are expected to be accessed or multicasted. This requires
something like a "scope" discovery protocol.

** Security Consideration section

Here is some text I propose. Comments are more then welcome! I hope
that we will be able to fix this section during the next meeting.

1. Scalable DNS Service is not an extension of SD in term of security

Scalable DNS-Based Service Discovery can hardly rely on the security
considerations defined for DNS-Based Service Discovery [RFC6763].
Considering "Scalability" requires new security practices that are
defines in this document.

DNS-Based Service Discovery [RFC6763] has been designed so that a
device can announce a service to the other devices of the network.
Although DNS or mDNS can be used for SD, SD has been mostly thought to
work over mDNS to avoid DNS zone management and to handle UTF8 names
for the end users even in the domain part of the Instance Service
Name. As a result SD' security considerations rely on mDNS security
considerations, DNSSEC [RFC4033] for authentication and secure DNS
update [RFC3007] to secure DNS update [RFC2136]. These considerations
are not sufficient for SSD as explained below.

    - a) DNSSEC is probably the DNS extension that MAY be used to
provide authentication and integrity check protection. However,
authentication other than proof-of-ownership or leap-of-faith security
model requires trust anchors. Trust anchor MAY be provided by the
global DNS, but this has not been specified in SD. Section 10 of
RFC6763 illustrates how to populate the DNS with information but
clearly states that such interactions are out of scope of RFC6763.
Interactions between SSD and DNS cannot be specified in an
illustrative section.

    - b) Similarly, DNS updates are used by SD to cooperate with DNS.
These interactions are left as illustrative in RFC6763, which is not
sufficient for SSD.

    -c) mDNS security considerations are not sufficient for SSD. At
first, mDNS requires cooperative devices. If cooperative devices is a
reasonable assumption in a one hop network such as most home networks,
this assumption cannot be made for larger networks, such as corporate
networks for example.

       In case all devices cannot trust each other, SD considers the
use of IPsec or DNSSEC. How these protocols are used is not fully
described in RFC6762 and SHOULD be at least documented for SSD. More
specifically, DNSSEC can be used with different security models.
Authentication of the devices may require a chain of trust and
interaction with DNS. Alternatively authentication may rely on devices
configured with certificates. In the absence of such certificates or
chain of trust, a proof-of-ownership with device's reputation may be
considered.

      mDNS considers the use of DNSSEC to differentiate responses from
the global DNS and mDNS that addresses a local scope. DNSSEC may not
be the appropriated solution for SSD as DNSSEC may not be deployed for
the global DNS or for mDNS which would make distinction impossible. As
suggested by RFC6761, the use of ".local" to specify mDNS may be more
appropriated.

      mDNS also raises the issue of relative domain names
(example.com) that may be solved as example.com.local. or as
example.com.search-domain. This issue becomes more complex with SSD.
For SD there is little ambiguity with the meaning of ".local". It is a
single link, usually a single network. SSD considers multiple links
and as such multiple ".local" and multiple different search domain.
Thus the question may be which link's search domain is to be
considered.

      mDNS considers very few interactions with DNS. The only
mentioned case is when a global DNS resolution is performed using
mDNS. mDNS indicates how to treat relative domains. Interaction
between mDNS and DNS was not so necessary as with one hop network
there is a clear separation between the local and non local (Internet)
network. With multiple networks, the frontier between local and non
local becomes much undefined. As result whether naming resolution is
local (mDNS) or global (DNS) is not obvious. This is why SSD needs to
specify interactions between DNS and mDNS whereas DNS-Based Service
Discovery [RFC6763] does not. As a result security considerations for
SSD considers 1) security considerations of SSD over mDNS, 2) security
considerations of SSD over DNS and 3) security considerations on
interactions between DNS and mDNS.

As a result, security assumption of DNS-Based Service Discovery
[RFC6763] are not any more valid for Scalable DNS-Based Service
Discovery.

1) Privacy protection

Information provided by SSD may contain private information that is
not expected to go outside  the specified scope.

Service Discovery carry information about the type of devices
available in your network, the software version, their location both
physical like floor as well as networking - like the IP address. All
these pieces of information may be useful for an intruder. Device and
software information are useful to identify vulnerabilities, and
location information are useful to locate the target, names may also
include information that may be useful to define a specific target -
like "Personal CEO Printer". For these reasons, one is willing to
limit the scope these pieces of information.

    a) Informations spreading may be limited based on network
information. When DNS is used, the DNS zone SHOULD NOT be accessed by
anyone from outside the specific network. This can be performed at the
DNS server level or at the network boundaries by setting firewall
policies specifying which kind of IP address can access the DNS
server. When mDNS is used, multicasted information SHOULD NOT be
forwarded outside the expected network. This can be performed by
firewalls that drops outbound/inbound mDNS packets at the network
boundaries. Note that in both cases, these policies are outside the
scope of mDNS or DNS. On the other hand, for mobile devices, for
example, which information may be provided depends on the network.
These policies have to be implemented by the mobile device.

    b) SSD SHOULD also consider scopes that are not correlated to
network definitions like 'building' or 'room'. As defined in the
charter:
"It is also desirable that multiple discovery scopes are supported,
from the point of view of either performing discovery within a
specified scope or advertisement within a specified scope, and
being able to discover (enumerate) the set of scopes such that
an application could then choose to do either. It should be noted
that scope in this sense might refer to 'building' or 'room' and thus
might have no correlation to network topology."

This requires 1) definition of the different available scopes. Some
default value MAY be provided by the device without knowledge of the
specific available scopes of the network. Such default values MAY be
used by devices if they do not discover the different scopes specific
to the network or if the device does not have sufficient information
to trust the announced scopes. In that case the device MAY start with
a default limited scope. 2) Specific network values SHOULD be
announced in an authenticated way to avoid that, for example,  non
existing scope used results in service unavailable. The policy for non
existing scopes SHOULD be defined with a reduced scope, and the device
SHOULD be informed that the scope does not exist so it may update its
scope. 3) Once devices have been informed of the various scope, it MAY
chose the one that seems the most appropriated and provide this
information. Depending on the scope, routers or middle boxes MAY chose
to forward the information or not. The information MAY be forwarded on
multiple links. With scopes that are not network correlated, the
information MAY be forwarded to a subset of devices within a link. The
use of distinct multicast IP address may be used to distinguish the
different scopes. However, the use of different IP addresses does not
prevent devices to listen to the information. If the device needs the
information to be read only by the members of the scope, cryptography
MAY be used to encrypt the data. IPsec multicast extension [RFC5374]
may be a good candidate. This mechanism may also be used to prevent an
unauthorised device to provide a service for a given scope. In other
words, my printer should not be able to announce its service for the
"CEO" scope and I should not be able to see the announcement of the
printer of my CEO.

2) Exposing Services

A Service announced over a network does not mean the service is
available to anyone. Such services SHOULD enforce access control
policies for the service.

If a connected printer is not using SD, it MAY appear as a simple IP
connected device attached to the network. Only specific
tests/scans/traffic monitor can determine the device is a printer.
When SD or SSD is used, as soon as the device is plugged on the
network everyone knows "Photo Color Printer, Building A floor 2" has
been plugged. If this printer is reserved for the Graphic an Design
department, than the printer SHOULD implement access control
mechanisms. Although these policies are out of scope of SSD, they MAY
be required as a consequence of SSD.

2) Resource exhaustion

With new emerging types of networks like sensor networks and more
generally the IoT, SSD cannot anymore rely on mDNS and multicast to
advertise its services and SHOULD provide a dedicated entity that can
perform SSD via unicast messages. Typically, this can be deployed with
a mDNS-to-DNS agent that receives announcement from mDNS devices and
stores this information to the DNS zone. Since the information is
stored, other devices in the network do not have to receive and treat
mDNS announcements.

SSD MUST be able to scale to thousands of devices. The use of
multicast for service announcement requires that each device informs
all other devices some information like the hosted service for
example. In order to make sure devices always have the information
up-to-date or that any new device has the information, the device
regularly retransmits the information to all other devices. This is
not a scalable architecture as it does not scale in term of bandwidth
nor it consider energy consumption constrains of small devices.

Any messages are bytes received by the devices connected on the
network, which may require additional processing such as cryptographic
check if used in conjunction with DNSSEC for example. These devices
may rely on battery, and each of these messages directly impact the
lifetime of the device. As a result aggressive multicast may
unnecessarily affect IoT devices. More rational approach MAY consists
in making possible SSD using unicast communications only or to prevent
that IoT device wakes up at every multicast message or using multicast
to announce information updates as opposed to cache populating. More
specifically, a new device can use multicast to announce a newly
published information. Eventually this information may be cached by
always-on devices and stored in the DNS. A new device may get access
to these pieces of information with an unicast AXFR for example. The
main advantage is that multicast interface can be switched off.

So here we're in similar territory to the discussions about RAs, and
multicast on certain types of links, which has led to the efficient-ND
proposal, and related work on energy efficiency for low power devices
etc. [http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt]

3) Trusted Scalable Service Discovery

This section is only focused on how information provided by the SSD
can be trusted. As every device announce their service, SSD SHOULD
prevent an attacker to announce it is the "CEO Printer" in order to
collect all documents printed by the CEO.
In this section, we consider that "CEO Printer" does not exists and
that the attack does not aim at hijacking a specific name. Using the
SD terminology "CEO Printer" would be the Instance part of the Service
Instance Name.

a) User perspective
When DNS is used, DNSSEC can be used, and one can trust the
information as it provides from a trusted party. Although DNSSEC has
not been designed as a protocol that certifies the validity of the DNS
RDATA, in our case, DNSSEC could be used as such. Contrary to
registrars that are hosting FQDNs they have very few knowledge on,
network administrators are expected to administrated the DNS zone
according to the resources available for the network. As a result
DNSSEC validation could be interpreted as "validated by the
administrator".

mDNS does not have trust anchors provided by DNSSEC. However, DNSSEC
used in conjunction of mDNS can be used to provide a
proof-of-ownership of the information. How reliable is that
information can be learned over time by processing the reputation of a
device (represented by its public key) or by monitoring whether the
information remains coherent over time. For example, if a printer
announces its IP address as part of the company network, and suddenly
starts announcing an IP address located somewhere else, further checks
may be performed before trusting the information. Even though the mDNS
message signed with DNS cannot be trusted the same way as it would
have been trusted in a DNSSEC zone, using DNSSEC in conjunction of
mDNS makes possible to assign some pieces of information to a specific
key. This helps in establishing a reputation as well as avoids spoofed
messages.

On a user perspective, mDNS requires the end user to establish a
reputation mechanism whereas DNS provides certified information. The
main advantage of DNS is that a new end user has certified information
which is not possible with mDNS.

[TBD check/compare hybrid model]

b) Devices perspective

When DNS is used, the device MUST be able to provide the information
to the DNS server via DNS update [RFC2136] or secure DNS update
[RFC3007]. This scenario may not meet a Zero configuration requirement
as the DNS server needs to know the public key of the devices, and the
device needs to know at least the IP address of the DNS server. If
DHCPv6 the IP address of the MAY be derived from the Domain Search
List and the DNS Recursive Name Server option [RFC3646]. The device
MAY send a DNS query for one domain search with type NS to the
recursive name server. However, registering the public keys of the
devices in the DNS does not scale thousands of devices. Most likely,
their public keys may be considered as trusted based on reputation,
leap of faith principles which does not necessarily prevent an
attacker to set false data into the DNS zone.

When mDNS is used, the device does not need any configuration. This
information is announced to the network. The information will be
trusted by the devices that trust the announcer. As for the DNS,
provisioning all devices of the network with all public keys is not
scalable. As mentioned above, public keys will be trusted most likely
based on reputation or leap of faith principles.

The main difference between DNS and mDNS seems that DNS requires less
provisioning or configuration than mDNS (n versus n * (n - 1) for a n
device network). Then in a zero configuration scenario, DNS
centralises in a single point the way a key can be trusted. The only
disadvantage of using DNS is the devices should discover the DNS
server.

It seems that approach combining mDNS and DNS can take advantage of
both. Devices announce information using mDNS and the DNS according to
the level of trust stores the information in its zone.

4) Information impersonation

The previous section provided considerations on how a device can be
associated to a public key and eventually identified as a trusted
device. With zero configuration, the level of trust associated to a
device results of a trade off between configuration and a learning
process. This section indicates how information provided by the
devices can be monitored to determine the reputation of a device, to
raise an alarm to the administrator, and eventually show a device
cannot be trusted or indicate a device has been  corrupted.

The kind of informations provided by SD or SSD that are visible to the
end user are 1) a name that describes a service and 2) the location of
the service. The name of the service corresponds to Service Instance
Name. With SD the name is mentioned in the RDATA part of the PTR and
as the key of the SRV RRSet. The location of the service is the RDATA
part of the SRV as well as its corresponding locator.

The Service Instance Name is composed of three parts: Instance,
Service Name and Domain. SD recommends that Instance and Domain are
encoded using UTF8. UTF8 enables specific characters that are not yet
being considered in the current DNS. Traditional DNS uses ascii or
Punycode. If UTF8 is more flexible in term of string representation,
it may provide multiple ways to express the same thing which may
confuse the end user. In fact using UTF8 "My Printer", "my printer"
"My printer" are different strings. This may be used by an attacker
that will provide a service different in term of UTF8 format, but that
the end user will assimilate to the same service. In addition, "my
printer" will be displayed differently if encoded in UTF8 or in ascii.
As a result two service "my printer" could be stored in a DNS zone
without any collisions.
One way to avoid multiple format would be to consider the necessary or
missing characters provided by UTF8 and add them in the Puny code.
If there may be some advantages in using UTF8 for the service name,
the domain name part SHOULD use only the Punycode.
As a result, checking information for SSD requires to establish
metrics/similarities between strings.

Worth noting in the DNS the device might be
hpprint01.bldg32.somesite.com, while its internally stored label may
be "Building 32 foyer printer".

The location of the service is identified by a FQDN and a
corresponding IP address. In SD, the FQDN respect the Punnycode
encoding. The FQDN of the service may be checked against the known
domain names associated to the network. Similarly, the IP address is
generally used to locate the service. if the IP address is not inside
the network, this may raise a warning to the administrator, that may
validate the IP address.

When DNSSEC is used closed names addressed by different keys are
suspicious. Without the use of DNSSEC is becomes hard to detect the
device/SD device has not changed their IP address.

5) Unique network identifier

SD uses ".local" prefix to indicate the scope of the FQDN.  ".local"
is a special use domain name - RFC 6761, and in the registry at
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

".local" is instantiated in any networks. This results in a given
string with multiple meanings. "My Printer" at home is not the same
service as "My Printer" at work and if the information is cached in
some devices, this may result in cross site name hijacking. An
attacker could for example advertise "My Printer" in a public network
like in an airport with a global IP address. The Service Instance Name
used could be something as "My Printer_ipp_tcp.local SRV
global-printer.example.com". People in the airport may then send their
documents to "My Printer" advertised in the airport - that is to say
global-printer.example.com -, instead of the one of their office.

In order to mitigate this confusion, ".local" SHOULD be used only when
the device does not know the domain name associated to the network. If
DHCPv6 is used this may be derived by the DHCPv6 Client FQDN option
[RFC4704].

Note also that "My printer" may be a different printer when I am at
home or at work. On the other hand, while at hoe I SHOULD be able to
use "My Office Printer" and vice versa. This ambiguity may be leverage
by the use of unique prefix.

6) Compromised device

This section estimates how a compromised device impacts the SSD
service. We assume DNSSEC is used.

Once detected, the public key associated to the device is revoked.
With DNS the revocation occurs once in the DNS, and the information is
only stored in the remaining caches of devices that have requested the
information before it expires. After TTL seconds, the information is
revoked from all devices. If mDNS is used, revocation should occur in
every device. The mechanism to detect a device is compromised is
complex and will probably not be implemented properly in most devices.

With the current SD, a compromised device MAY provide wrong
information about itself but does not affect others device
information.

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58