On Tuesday 23 June 2015 01:37:35 Carsten Bormann wrote: > Thiago Macieira wrote: > > Indeed. The security team should figure out a way so that discovery can be > > secured against eavesdropping. > > We don't have a standard way to do this (at the CoAP level). > Of course, if your network uses encryption, then you already have some > protection.
Right, but not against eavesdropping from someone who did join the network. Most people these days give their network passwords to guests when they come to their places, instead of creating a separate network for guests. And this is for people who did set a non-trivial password for their WiFi networks... > > reply should be secure. Either way, the client sending the discovery needs > > to list which port number it's listening for DTLS unicast replies on. > > That doesn't work either: The DTLS endpoint is separate from the UDP > endpoint the multicast was sent from -- the response wouldn't match the > request. Understood. That's why the discovery request needs to include the secure port number in the payload. > http://tools.ietf.org/html/rfc7252#section-9.1.2 > > You could use two-step discovery: Only expose a single discovery > resource on a DTLS-secured discovery endpoint in the unsecured > /.well-known/core; then do discovery on that via DTLS. The only thing > you really expose is the IP address, and that is already visible in the > packet. This is something that John suggested: making an unencrypted discovery for a directory server, then securely discover services from that directory. This way, we solve two problems with one stone: we won't flood the network with discovery and wake up every single device when looking for a particular one. > All this doesn't really answer the question where the keys for the DTLS > connection would come from. If you are still doing discovery, you may > not know the other guy well enough (and v.v.) to talk to them securely. > (DCAF might help here.) Provisioning should happen during the onboarding process. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
