| RFC draft-sweet-iot-acme-03 | ACME IoT Provisioning | February 2023 |
| Sweet | Expires 10 August 2023 | [Page] |
This document extends the Automatic Certificate Management Environment (ACME) [RFC8555] to provision X.509 certificates for local Internet of Things (IoT) devices that are accepted by existing web browsers and other software running on End User client devices.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 10 August 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
IoT devices are common on local networks and often utilize TLS [RFC8446] with self-signed X.509 certificates [RFC5280] to provide HTTPS [RFC2818] based web pages and services. Unfortunately, web browsers typically do not trust such certificates and show error messages intended to deter usage.¶
The Automatic Certificate Management Environment (ACME) [RFC8555] defines a protocol for network services to obtain trusted X.509 credentials for use with TLS [RFC8446]. However, since existing ACME Servers depend on public Internet connectivity to the ACME Client for validation, and since those same servers cannot issue X.509 certificates for the ".local" domain, some changes are needed to support a local ACME Server.¶
This document uses existing infrastructure, namely the network's DHCP [RFC2131] and DNS [RFC1034] services, to find the local ACME Server when connecting to a network. Extensions to ACME are defined to support local ACME Servers. Local ACME Servers can be standalone servers (common in enterprise networks) or software that runs on a consumer Internet router/modem, and are discovered using either a DHCP option or a DNS-SD [RFC6763] service record from the network's DNS service.¶
Client Devices access the local ACME Server to obtain the local site's signing certificate, which is then used as a local trust anchor to validate IoT Device X.509 certificates. IoT Devices access the local ACME Server to obtain X.509 certificates for use on local network(s). X.509 certificates issued by the local ACME server are only valid when accessing the IoT Device for the local DNS domain, the mDNS (".local") domain, or any link-local or private IP addresses.¶
Because devices often connect to multiple, unconnected networks, trust and usage of X.509 certificates provided by a local ACME server is limited to the currently connected network, essentially creating an intermediate trust level below global Certificate Authorities (CAs).¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].¶
Client and IoT devices discover the local ACME Server using one of two methods (in order of precedence):¶
Most home networks will use the DHCP Option, while larger (enterprise) networks providing a dedicated DNS domain will use the DNS-SD query.¶
Note: DNS-SD queries MUST NOT be performed using Multicast DNS (mDNS) [RFC6762] for security reasons.¶
ACME [RFC8555] defines a protocol for managing trusted X.509 certificates. Organizations such as "Let's Encrypt" provide publicly available ACME servers, and such servers have led to the ubiquitous usage of TLS for internet web and email servers. However, public ACME servers typically cannot access local (private) devices and will not issue certificates for the mDNS ".local" domain. A local ACME server can both access local devices and issue certificates for local domains.¶
A local ACME server will typically generate a self-signed X.509 certificate as its root (CA) certificate and the local network's trust anchor. The certificate MUST use a SHA2 hash of at least 256 bits and MUST use either RSA encryption with a key length of at least 3072 bits or ECDSA encryption with the secp384r1 (P-384) or secp521r1 (P-521) curves. The expiration of the self-signed certificate MUST be between 1 and 10 years, inclusive. The certificate MUST contain subjectAltName extensions for ".local" and the local domain name(s), and MAY contain subjectAltName extensions for the current IP address(es) of the server.¶
ACME account objects contain an array of contact strings. Normally this array consists of "mailto:" URIs, however for local IoT devices an array of "https:" URIs should be used instead, one for each fully-qualified domain name used by the device.¶
The certificate signing request supplied by the IoT Device MUST use a SHA2 hash of at least 256 bits and MUST use either RSA encryption with a key length of at least 3072 bits or ECDSA encryption with the secp384r1 (P-384) or secp521r1 (P-521) curves. The request MUST also contain subjectAltName extensions for ".local" and the local domain name(s), MAY contain subjectAltName extensions for the current IP address(es) of the device, and MUST NOT contain subjectAltName extensions for "localhost". For example, if the device name is "device-12cd56" and the local domain is "example.com", the signing request will at least contain two subjectAltName extensions with values "DNS:device-12cd56.example.com" and "DNS:device-12cd56.local".¶
Certificates generated by the local ACME server MUST have an expiration of three months or less.¶
Client Devices, upon connecting to a network, MUST use ACME Server Discovery to determine whether the local network has an ACME Server. If it does, the Client Device connects to the server using HTTPS and copies the X.509 certificates for use in validating future connections to IoT Devices. The Client Device SHOULD utilize a TOFU validation policy for self-signed X.509 certificates unless otherwise configured, for example in a managed enterprise network environment.¶
The Client Device MUST NOT use the supplied X.509 certificate when validating certificates on other networks. The certificate is typically associated with the network interface name, network SSID, and/or MAC address of the default router and MAY be associated with the local domain name. Client Devices MUST NOT use ".local" host names or IP addresses to validate the CA certificate since those values are not unique. A certificate MAY be used for multiple networks, for example with a wireless cable modem that provides both Wi-Fi and Ethernet connectivity.¶
IoT Devices, upon connecting to a network, MUST use ACME Server Discovery to determine whether the local network as an ACME Server. If it does, the IoT Device connects to the server using HTTPS and uses the ACME protocol to obtain, renew, or verify an X.509 certificate for each network the device is connected to. The IoT Device SHOULD utilize a TOFU validation policy for self-signed X.509 certificates unless otherwise configured, for example in a managed enterprise network environment.¶
The IoT Device MAY share certificates between networks when those networks utilize the same ACME server and X.509 certificate.¶
The security considerations of IoT provisioning are similar to those described in [RFC1034], [RFC2131], [RFC6763], [RFC8446], and [RFC8555]. The following subsections describe additional security considerations.¶
This specification necessarily depends on all devices trusting the underlying network infrastructure, specifically the local DHCP and DNS servers. Sites can utilize Network Endpoint Assessment [RFC5209] and Trusted Network Connect (TNC) [RFC5792][RFC5793] to provide enhanced security and trust in the local network.¶
The local ACME Server MUST validate the subjectAltName values in certificate signing requests from IoT Devices. DNS name suffixes MUST be restricted to ".local" and the configured local domain name(s), and the leftmost label MUST NOT be the name of the local ACME Server or "localhost". IP addresses MUST be limited to link-local, loopback, and private use addresses.¶
Because the local ACME Server will often rely on a self-signed certificate and TOFU validation policy, a man-in-the-middle attack is possible with successful DHCP, DNS, and/or mDNS request interception and/or redirection. Such attacks can be detected using network monitoring tools, and the use of a long-lived root certificate helps to mitigate the possibility that compromised network connections or infrastructure will go undetected by the Client Device.¶
It is important for all devices to protect stored encryption keys from disclosure. Disclosure of the local ACME Server's private key will compromise all encrypted traffic on the local network. Disclosure of an IoT Device's private key will only affect that device's traffic.¶
All devices MUST provide a way for an End User to revoke or re-issue X.509 certificates and regenerate a new private/public key pair for certificates and certificate requests. The most common way is through a so-called "factory reset" process that restores a device to its original, factory configuration/state.¶
Multicast DNS (mDNS) [RFC6762] has a number of known security limitations. DHCP Option NNN provides the local ACME Server's fully-qualified domain name which can be resolved using mDNS, providing a small window for a man-in-the-middle attack during initial device connection. Such attacks can be detected using network monitoring tools and/or through the use of a root X.509 certificate from a trusted, public CA on the local ACME Server.¶
Multicast DNS (mDNS) domain names ("example.local.") can collide with other network devices. While mDNS does define an algorithm to resolve name collisions, IoT Devices SHOULD use a default name with a unique identifier, e.g., "device-12cd56.local.", so that name changes are less likely. When an IoT Device's mDNS changes, it MUST revoke all certificates for the old name with the local ACME Server and request new certificate(s) for the new name.¶
Client and IoT Devices SHOULD identify networks using the local network interface name, MAC address of the default router, and/or the Wi-Fi SSID and validate the local ACME Server's root certificate when connecting. Wi-Fi validation is necessarily limited since Wi-Fi SSIDs are not unique. Client Devices MUST and IoT Devices SHOULD notify the End User when the root certificate changes for a network.¶
Multiple network configurations pose an interesting implementation challenge. The most typical multiple-network configurations are Wi-Fi + cellular and Wi-Fi + Ethernet, where cellular networks are usually public-facing with no mDNS while Ethernet networks are usually private with mDNS support.¶
Client Devices MUST separately track and validate the root X.509 certificate for each local ACME Server. Similarly, IoT Devices MUST separately track, store, and use X.509 certificates for each local ACME Server.¶
In accordance with [RFC2132], IANA has added the following new DHCP option to the BOOTP Vendor Extensions and DHCP Options [DHCP-REGISTRY] registry:¶
Tag: NNN¶
Name: ACME Server¶
Data Length: N (variable length)¶
Meaning: Fully-qualified domain name of the local ACME server¶
Reference: This document¶
In accordance with [RFC6335], IANA has added the following new service name to the Service Name and Transport Protocol Port Number Registry [SERVICE-REGISTRY]:¶
Service Name: acme-server¶
Port Number: None¶
Transport Protocol: tcp¶
Description: Automatic Certificate Management Environment (ACME) server¶
Assignee: Michael Sweet¶
Contact: Michael Sweet¶
Reference: This document¶
Assignment Notes: Defined TXT keys: None¶
[ RFC Editor: This section to be deleted before RFC publication ]¶
February 6, 2023 - draft-sweet-acme-iot-03¶
July 14, 2022 - draft-sweet-acme-iot-02¶
April 14, 2022 - draft-sweet-acme-iot-01¶
April 6, 2022 - draft-sweet-acme-iot-00¶