Addressing background
Addressing primer
The concept of a device end point name and its physical internet address are intimately intertwined with negotiated security. Current HTTPS security semantics rely on the fact that a public key is bound to the devices referenceable name. The TLS negotaion provides the client the necessary guarnatees that the server is in posession of the private key, which corresponds to the public key tied to the name, in the presented certificate.
Let us define the following terms to help understand the solution space
- Browser: the browser is an application used by a use to browser web content.
- Target device: the target device is the IOT device with the user is attempting to connect to (or configure) using the browser
- Name: the name (or device name) from the browsers perspective is the string typed into the browser address bar, which corresponds to the target device
- Name resolution: the name resolution process is the method used by the browser to turn the name into an address
- Address: is the physical (IP) based address that can be used for routing packets to the target device
Building on these basic concepts, the following higher level concepts are also important
Unique names and address binding
Each device can be given an unique name. For example the hash of self generated public key of a device, can often be used to name a device with relatively strong guarantees of uniqueness. For this name to be useful, however it must be resolvable. For this name to be resolvable over the internet, the unique device name will have to be combined with the address of a parent domain, to create a compound name.
Where DNS is being used as the name resolution process, we can construct the compound name in a device binding event.
There are a number of potential provides of parent (bound) domains
A private person could acquire a personal domain
The network provider could dedicate a subdomain to the users.
A device vendor can create a subdomain for its devices
An authority can setup a domain name dedicated for devices.
Private persons may not have the interest or technical capabilities to operate a domain. It could be made easier if domain and certificate management would be integrated in a home gateway, network storage devices
On the other hand device manufactures may have a limited timespan in which they are interested in operating an infrastructure for their devices.
An authority similar to how ISRG governs Letsencrypt could operate a device dedicated domain. Since it is in the public interest, this would deserve to be government funded by participating nations or unions.
Clearly, the definition of this process has profound impact on the commercial ecosystem to be developed. It is therefore important that the solution proposed does not lock us into one operating economic model
Where a traditional certificate is used, this process is essential as the derived compound name becomes the common name of the device to which the certificate must be issued. Hence, name construction must happen before certificate issuance.
tip
Binding the device and provisioning it with a globally resolvable DNS name, is a real world (economic) event, which also impacts the construction of certificates (is that is the method being used)
IP Addressing and Network
Concerning the device address: Local network addresses have identifiers that are distinguishable from public internet addresses. These IP addresses will be locally significant only. They can only be reached if traffic towards global addresses forward the traffic. These addresses are reserved as link local, private use or are shared and are not globally unique. They are listed as Special-Purpose IP Address Registries https://datatracker.ietf.org/doc/html/rfc6890
| Purpose | IP Range |
|---|---|
| Private-use | 10.0.0.0/8 |
| 172.16.0.0/12 | |
| 192.168.0.0/16 | |
| Link Local | 169.254.0.0/16 |
| Shared Address Space | 100.64.0.0/10 |
| Unique Local | fc00::/7 |
| Linked-Scoped Unicast | fe80::/10 |
Browsers can distinguish between publicly routed internet addresses and private-use or link local addresses. When a browser negotiates a TLS session with a server, the browser can detect that the server is reachable through a special purpose IP address. The certificate warning displayed to the user can be different in this instance, because the context is local and not on the global internet.
Firefox has a method hostnameIsLocalIPAddress to check if an IP address is local or not [nsIIOService.idl - mozsearch]
https://searchfox.org/mozilla-central/source/netwerk/base/nsIIOService.idl#201
tip
The resolved IP address of the target device, is a critical part of current security decision making, in browsers
note, tip, important , caution , warning
DNS domain name resolution
In a local network there is often no registered and resolvable DNS domain name, especially for devices that are not supposed to be directly connected to the internet.
The local device addressing method is important for two reasons. Firstly, traditional HTTPS certificates are essentially cryptographic bindings between a common name (and address) and a public key. Secondly, the discoverability and usability of the local address will directly impact the user experience.
TLS certificates are valid for the identifier presented in the common name or subject alternative name. The most common identifier is a DNS name, but also public IP addresses are allowed. Root CAs are not allowed to sign certificates if these identifiers use internal names. The domain name must be registered and resolvable. https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf
The naming mechanism is important also because the current browser standard is DNS resolution. The interaction of DNS resolution, proof of DNS ownership and certificate issuance are all intimately intertwined.
Solutions therefore will fall into two broad categories:
- Methods restricted to current standard DNS address resolution semantics.
- Methods that introduce new addressing mechanisms. These solutions offer more room for innovation, but necessarily will require deeper changes to the browser.
tip
The DNS name resolution process is an integral part of current TLS session negotiation. A new security model for browser/IOT interaction, either needs to fit into the current DNS model or replace the name resolution with another mechanism
Multicast DNS
On the internal network (private IP address space) a different name resolution mechanism can be used.
Common practice is to address devices by a private IP address, which some devices advertise through Multicast DNS. This makes the devices discoverable, but it does not make them uniquely identifiable.
Multicast allows a device to advertise itself on the network and to be reached with a common name.
mDNS uses the domain suffix .local (IETF RFC6762) and IPv6 has a link-local scope and unique local address range fe80::/64. These addresses are often on the same physical ethernet link. It is possible for a browser to identity the local context. For local connections a different error message can be displayed. https://datatracker.ietf.org/doc/html/rfc6762
CA/Browser Forum does not allow for the .local suffix to be signed.
tip
Multicast DNS can be used as an alternative local name resolution method. However some networks disable it so it cannot be assumed to always there
Link Address
Most devices already have a unique identifier like a MAC address for ethernet, Wi-Fi or Bluetooth. The MAC address is a link level address in a network. Currently the MAC address is not typically used in the negotiation of security between client and server. However, there is a clear opportunity to introduce such concepts. The Organizational Unique Identifier which is part of the full address, conveys meaningful information about the original manufacturer. There are use cases where this information can be useful in establishing security credentials. MAC addresses however can be modified and spoofed in most circumstances.
It's possible for the browser to identify that a resource is on the same physical link, however many devices are not on the same physical link and will be connected through routers, access points or switches. The link local address in IPv6 may be derived from the MAC address.
X.509 certificates used in TLS require a verifiable public IP address or a public DNS name. Other X.509 based schemes exist that certify other layers in the network stack.
tip
The link level address of the target device and/or security artefacts (e.g. certificates) attached to the link level address could be used as part of the security, decision making process
Network Segmentation
Network segregation is generally good security practice. At a crude level the distinction between private use address(192.168.0.0/16) and global IP addresses is a form of segmentation.
A dedicated IOT network using a private VLAN could create a separate communication channel for device management isolated from other network traffic. A browser and gateway would have a method to identify IoT devices and "perform differently". A private VLAN dedicated to IoT could for instance be set to 2107. https://datatracker.ietf.org/doc/html/rfc5517
However currently browsers are not considering the VLAN network they are operating in and it would require a significant standardisation effort to change the current networking practices to protect IoT network traffic.
tip
Internal network subnets, could be used to segment or separate out clusters of devices. These clusters of physical addresses could be used as part of the browsers security decision making process