[Tfug] Static/Dynamic (IP,name) bindings enupu1er

[Bexley Hall]

Hi Nathan,

--- On Thu, 9/13/12, Nathan Hruby <nhruby at gmail.com> wrote:

> That sounds really complicated.

Why?  It's just adding a digest to each transaction (hashed with a
private key) to vouch for the content of that transaction.
 
> Why not just make the DHCP server
> update DNS vis DDNS using a preshared key?  Examples:
> - http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/
> - http://hackerific.net/2007/12/24/dynamic-dns-with-dhcp-and-bind-9/
> 
> Yes, a rouge DHCP server could still poison your clients and do bad
> things.  If you believe that's an attack vector that you're at risk
> for, using WPA-enterprise on private WIFi, captive portals + traffic
> limiting on public networks, port-based security / mac filtering,
> 802.11x, and good old good physical security are good things to do to
> limit your risks.  Most of these features are available on
> out-of-the-box consumer grade network hardware and only require a
> minimal amount of setup (some features assume you have things like
> ldap or radius available and may not be immediately useful).
 
A lot of dependencies whereas the *one* feature addresses all of
these concerns.  I.e., "sign" each transaction -- including the
normal run-time traffic that the device would encounter!
(i.e., the authentication also protects "commands" issued to
the device *after* it has booted)

The scheme I've come up with so far:
- devices are manufactured as "identical units" (perhaps with
  unique MAC's -- though not required)
- device is "introduced" to the HA system via a secure communication
  mechanism (i.e., a crossover cable connecting it's NIC to that
  of the HA system WITH NO POSSIBILITY OF EAVESDROPPING).
- device and HA system negotiate private keys and unique identifiers
  (HA system can just keep incrementing a wide counter each time it
  encounters a device.  You don't care if the identifier is globally
  unique as long as it never conflicts with another ID that you
  have issued locally!)
- device stores its ID and key in nonvolatile memory; HA similarly
  records the key associated with that ID (disk, etc.)
- HA system expects all incoming requests with that ID to be signed
  based on this pair of keys and generates its replies similarly.
- device knows reply originates from HA system (no forgeries) based
  on these keys as well

Now, a DHCP request is nothing more than any *other* transaction
between the device and the HA system.  A binary executable
downloaded to the device isn't acted upon (i.e., loaded and
executed) unless it similarly passes its authentication.

Similarly, a command to "change temperature setpoint to XXX" is
ignored[1] if it fails this authentication.

I.e., there is nothing "special" about a DHCP request.  Or a
change setpoint command.  Or...

And, there is no added requirement imposed on the devices that
make up the network infrastructure!  E.g., you can replace a wired
network with an ad-hoc *wireless* network without having to change
any of the software in the device or HA system!

Finally, its simple for the user: "register" the device with the
HA system, then deploy it.  Just like "registering" a cordless
phone with its base before use!  I can't think of anything
more straightforward (especially one that allows identical devices
to be mass-produced!)

----------

[1] The command is not acted upon but it is not "ignored".  You
track the frequency of these authentication failures and use
that knowledge to determine if you have a communications problem,
software bug *or* a potential attack underway.