DNS Based Device Name - Embedded physical address

In order to avoid changes to the current browser and certificate practices. The Device DNS Name provides a method to globally resolve a DNS name for each provisioned IOT device. It will resolve to a local address. Because this gives the device a global name, it is possible for a Certification Authority to sign the certificate under the CA/Browser Forum rules.

This approach attempts to solve this issue with no alterations to the browser or CA/Browser Forum policies. As long as the brower recognises the signing CA and the device domain name can be validated by the signing authority. It is designed to be extensible to fully-offline versions, which may not need CA/Browser Forum alterations.

This requires encoding enough data in the name that both the address and the device's cryptographic identity are expressed in the URL.

The server can build the name it announces based on the local network situation, and a web service between the device and any ACME compatible CA (like LetsEncrypt) can verify the identity and thus have a valid global certificate issued.

Names can be issued under any domain that runs such a web service; let's assume vendor.example runs it. Then a device has a cryptographic identity and forms an identifier from it (in examples we're using f0ocrypto1d; actual names are longer).

It then identifies a usable IP address it is assigned (might be an actual IPv6 address, but IPv6 ULAs and IPv4 local addresses work as well) and encodes that into a second identifier (say c0a80001; actual identifiers for IPv4 will be shorter and for IPv6 longer).

The first option creates a device name as a concatenation of the physical address of the device and a bound domain, where the bound domain will resolve using normal global DNS resolutions methods

Name syntax

The BNF syntax represetning such a name is as follows

<local-name> ::= <local-address> "." <dev-id> "." <bound-domain>
// local address is IPV6 ULA or IP4 Private network address
<local-address> ::= {fc00::/7} |{172.16.0.0/12} | {10.0.0.0/8} | {192.168.0.0/16}
// dev-id is hash of device public key
<dev-id> ::= {}
// bound-domain is a publicly resolvable domain name, with which the device is provisioned
<bound-domain> ::= {}

This produces example device names of the form

https://c0a80001.f0ocrypto1d.devices.vendor.example

Where in this instance

  • c0a80001- is the physical address of the device
  • f0ocrypto1d- is the device ID - or more specifically the hash of the public key for the device
  • devices.vendor.example - is the bound domain - a publicly resolvable IP address

Name provisioning

For the above method to work, there needs to be a provisioning event, where the the <dev-id> is bound to the <bound-domain>

The pre-condition therefore is that a device is pre-provisioned with a bound domain. Ideally the system would also cater for multiple bound domains where device identities can be hosted in the DNS infrastructure of multiple parties. e.g.: original manufacturer, redundant resolver, distributor or another intermediary.

There are a number of scenarios to consider:

  1. Manufacturer provisioning: the device is provisioned in factory within the administrative domain of the original manufacturer.
  2. Service provider provisioning: the device is provisioned before point of sale within the administrative domain of the service provide (for example an ISPs address).
  3. Intermediate provider provisioning: the device is provisioned any point in the cycle with a manufacturer/service provider independent domain (for example a CA).
  4. User defined provisioning: the device is provisioned past point of sale within a home domain defined by the end user.

In order to assure continued functioning of a device in the situtation where the manufacturer or server provider no longer operates the bound domain service, we should encourage models which allow for simple user provisioning or back-up provisioning flows.

In the examples that follow we will use devices.vendor.example as a concrete instance of bound domain.

Assuming the bound-domain has been pre-provisioned, in order to make use of the "Device DNS Name" solution, the IoT device must undergo a one-off onboarding provisioning flow.

Security considerations

In this provisioning flow, steps 3 and 4 need to be protected. The DNS server being used to resolve the address and the CA processor which mediates the certificate request need to be protected against spoofed or non-permissioned provisioning requests

Name resolution

The operational flow is trigged, every time the user initiates a browser session with the target IoT device.

The user is expected to be in possession of the <local-name> (discovery) in order to initiate this process

Name validation (security)

This method has the advantage that it can piggy back on top of existing HTTPS certificate semantics and certificate issuing methods.

The issued certificates could make use of Key Usage and Extended Key Usage fields, so that local connections could be differentiated in the browser

Analysis

Draft

PLUS: uses existing certificate and DNS mechanims

PLUS: requires no change to browser

NEGATIVE: rebind problem discovered in trial means it does not work on current routers

NEGATIVE: requires manufacture to create new DNS services and CA services

NEGATIVE: could bind device to manufacture

Implementation notes

Link to SUIB-solution-cryptoname-details

Current problems encountered in testing

  • REBIND attack protection - means should not trust localDNS
  • need to sign DNS records
  • rebinding protection limits the applicability of this approach
  • DNS over HTTP avoids re-binding protection problem
  • limited IPV6 support
Edit this page