Subject: [mdnsext] Security requirement?

From: Matthew Gast <[email-masked]>
Date: Wed, 7 Nov 2012 06:59:13 +0000

Another item that emerged from today's BoF discussion was a somewhat
nebulous desire for security.  It's not really in the current draft of the
requirements document, so I'll start off with what I heard today, which is
that service advertisements shouldn't just be trusted, and that both the
service transmission and service reception should be validated.  If I were
to put that into the current document, I'd propose text like this:

"REQ06: Security.
- Enable validation of authenticity of service advertisements
   - Users and devices are only authorized to advertise certain services
- Service advertisements are only delivered to authorized recipients"

Matthew

---

From: Matthew Gast <[email-masked]>
Date: Fri, 9 Nov 2012 17:29:16 +0000

I agree with that addition, but I'd modify it slightly to say that we want
to continue to support the proxy functionality that exists today, like:

"- ensure that service resolution is authoritative for the advertisement,
whether it is an original or proxy advertisement"

I have no immediate idea for how to solve the proxy advertisement
authentication problem, but I'd like to try.  Given that we're trying to
address Wi-Fi problems, having a way to advertise services to clients that
have just woken up from a sleep seems like a good idea.

Matthew

On 11/7/12 5:21 PM, "Alf Watt" <[email-masked]> wrote:

>I'd add:
>
>- ensure that service resolution is authoritative for the advertisement
>
>i.e. prevent a third party from replying with it's own ip & port number
>to redirect a client for nefarious purposes.
>
>Solving this for both mDNS and DNS-SD would be a good thing.
>
>http://www.gnucitizen.org/blog/name-mdns-poisoning-attacks-inside-the-lan/
>
>Best,
>Alf
>
>On Nov 7, 2012, at 1:59 AM, Matthew Gast <[email-masked]> wrote:
>
>> _______________________________________________
>> mdnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mdnsext
>> 
>

---

From: Alf Watt <[email-masked]>
Date: Fri, 9 Nov 2012 20:17:01 +0000

Good suggestion, I used 'authoritative' to indicate that the actual advertiser or it's designated proxy could respond as long as we have a chain of trust, but it never hurts to be explicit.

Have a look at the Sleep Proxy[1] support for examples of how proxying currently works, the client adding a service to the proxy needs some way to transfer keys or a signature that indicates that it's OK with another agent on the network responding.

Best,
Alf

[1] http://stuartcheshire.org/SleepProxy/

---

From: Alf Watt <[email-masked]>
Date: Thu, 8 Nov 2012 01:21:39 +0000

I'd add:

i.e. prevent a third party from replying with it's own ip & port number to redirect a client for nefarious purposes.

Best,
Alf