Internet-Draft Home Servers September 2024
Reddy, et al. Expires 23 March 2025 [Page]
Workgroup:
network
Internet-Draft:
draft-rbw-home-servers-00
Published:
Intended Status:
Informational
Expires:
Authors:
T. Reddy
Nokia
M. Boucadair
Orange
D. Wing
Cloud Software Group

Identifying and Authenticating Home Servers: Requirements and Solution Analysis

Abstract

Obtaining CA-signed certificates for servers within a home network is difficult and causes problems at scale. This document explores requirements to improve this situation and analyzes existing solutions.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at https://datatracker.ietf.org/doc/draft-rbw-home-servers/.

Discussion of this document takes place on the ADD Working Group mailing list (mailto:add@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/add/. Subscribe at https://www.ietf.org/mailman/listinfo/add/.

Status of This Memo

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 23 March 2025.

1. Introduction

This document describes the problem encountered to host servers in a home network and how to connect to those servers using an encrypted transport protocol such as TLS [RFC8446] or DTLS [RFC9147]. It also identifies a set of requirements and discusses to what extent existing solutions can (or can't) meet these requirements.

This documnt uses "local equipment" to refer to an equipment that is deployed in a local network (e.g., LAN). A local equipment can be a Customer Premises Equipment (CPE), an IoT device, an Set-top box (STB), etc.

2. Scope

This document describes the current state of the art for deploying encrypted servers within the home. New mechanisms should be described in separate documents.

There are three types of equipment:

  1. Legacy local equipment which lacks memory, CPU, or sufficient security to reasonably support an encrypted transport protocol and associated key management. An example is a 10-year old router with built-in 802.11n Wi-Fi. This type of equipment is out of scope.

  2. High functioning local equipment that provides sufficient hardware and software capability to support an encrypted transport protocol and associated key management. An example is a printer, NAS, or higher-end consumer router. This is the primary scope of this document.

  3. High functioning virtualized equipment, where some functions are provided via local or remote software. An example is virtualized CPE (vCPE). This is a secondary scope of this document.

3. Requirements

This section identifies a set of requirements and discusses each of them.

3.1. Reduce Use of Public Certification Authority

With automated certificate enrollment and renewal [ACME], a public Certification Authority (CA) can sign a certificate for local equipment such as a printer, NAS, or router. However, this causes a few issues:

  • In case of large scale deployment of local equipment (e.g., millions of devices), issuing certificate requests for a large number of subdomains could be treated as an attack by the CAs to overwhelm it. This can be resolved with contracts/fees but this reduces agility and choice flexibility.

  • Dependency on the CA to issue a large number of certificates, which causes CA availability to impact service availability.

  • ACME-based challenges require a public WAN IP address for HTTP challenge or control of DNS zone, which is difficult or impossible for devices behind a NAT (e.g., printer). Even considering the home router this remains difficult as it needs to (temporarily) expose an HTTP server to the Internet during the HTTP challenge. An ISP-operated NAT (Carrier Grade NAT, CGN) is another barrier.

Deployed systems have used a vendor-operated service for certificate acquisition and renewal to avoid the problems enumerated above.

R-REDUCE-CA:

Reduce the use of a public Certification Authorities.

3.2. Eliminate Use of Public Certification Authority

Taking an additional step from the previous requirement, eliminating the vendor operation of a CA avoids the complexities of certificate management.

R-ELIMINATE-CA:

Eliminate using Certification Authorities for each device.

3.3. Existing Support by Certification Authorities

The ability to immediately deploy using existing CA is important to evaluate.

R-SUPPORT-CA:

Existing support by Certification Authorities.

3.4. Client Support

The ability to immediately deploy on clients is important to evaluate.

R-SUPPORT-CLIENT:

Existing support client libraries or client software intances.

3.5. Revoke Authorization

End-users are extremely unlikely to contact the device vendor if a device is replaced (stolen, upgraded, etc.). Rather, the users will replace the device and configure their clients (laptops, smartphones, IoT devices, etc.) to authorize the new device. As part of that configuration, the client can encourage removing authorization for the replaced device. In situations where there is normally only one device (one NAS, one printer, one home router, etc.), this revocation can be straightforward.

R-REVOKE-AUTH:

Provide a mechanism for an end-user to disable access to a previously- authorized encrypted service, to accomodate a lost/stolen/sold device.

4. Analysis of Solutions to Requirements

This section describes several solutions which can meet a subset of the requirements. This is first summarized in Table 1 and detailed in the following subsections.

Table 1: Summary of Solution Analysis
Solution Reduce CA Eliminate CA Existing CA Support Existing Client Support Revoke Auth
Normal certificates No No Yes Yes Some
Delegated credentials Yes, somewhat No No No, (*) Some
Name constraints Yes No No No Some
ACME delegated certificates No No Yes Yes Some
Raw Public Keys Yes Yes n/a Some, (*) Yes
Self-Signed Certificate Yes Yes n/a Yes, poor experience Yes
Local Certification Authority No No Yes Yes Yes
Matter Yes No Yes Yes Yes

4.1. Normal Certificates

This solution has the device send a request to a (cloud) server to obtain a certificate for the device from a public CA. This solution is deployed in production by Mozilla [https-local-dom], McAfee, and Cujo. Today, this is best practice. However, it suffers from the dependency on both the public Certification Authority and the vendor's service (necessary because the device cannot always obtain a publicly-accessible IPv4 address necessary to get an ACME-signed certificate itself), which are necessary for both initial deployment and for certificate renewal.

R-REDUCE-CA: no

R-ELIMINATE-CA: no

Both CAs and clients already support the normal mode of operation.

R-SUPPORT-CA: yes

R-SUPPORT-CLIENT: yes

R-REVOKE-AUTH:

Somewhat, if client retrieves CRL frequently and if CRL is updated frequently, and user has mechanism to declare the certificate as invalid.

4.2. Delegated Credentials

Delegated credentials [RFC9345] allows the entity operating the device (e.g., vendor or ISP) to sign a 7-day validity for the device's public key (Short-Term Automatically Renewed (STAR)). The frequency of CA interactions remains the same as with normal certificates (Section 4.1). For each device, the interactions are with the vendor's service rather than with the public CA.

As currently specified in [RFC9345], the same name would be issued to all devices making it impossible to identify whether the delegated credential is issued to the intended device or an "evil-twin" device. This drawback can be corrected by enhancing [RFC9345] to include a string that uniquely identifies the delegated credential (e.g., including hash of customer id or other unique identifier in the FQDN to result in "printer.<HASH>.example.com" or "nas.<CUSTOMER-ID>.example.net").

  • For the sake of simplifying the analysis, this document assumes such an enhancement to [RFC9345] has been standardized and deployed.

R-REDUCE-CA:

yes, somewhat by moving CA signing from public CA to a vendor- or ISP-operated service.

R-ELIMINATE-CA: no

Delegated credentials have no existing support by CAs. Clients need to support Section 4.1.1 of [RFC9345] which requires sending an extension in their TLS 1.3 ClientHello. The only client supporting delegated credentials is Firefox.

R-SUPPORT-CA: no

R-SUPPORT-CLIENT: no, only supported by Firefox

R-REVOKE-AUTH:

Somewhat, if client retrieves CRL frequently and if CRL is updated frequently, and user has mechanism to declare the certificate as invalid.

4.3. Name Constraints

Name constraints (Section 4.2.1.10 of [RFC5280]) allows the entity operating the device (e.g., vendor or ISP) to obtain a certificate from a public Certification Authority for a subdomain (dNSName) which is then used to sign certificates for each device. For example, the network "example.net" could obtain a name constrained certificate for ".customer.example.net" and then issue one certificate for each customer such as "123.customer.example.net", yielding "printer.123.customer.example.net" and "nas.123.customer.example.net" and "dns.123.customer.example.net". For each device, the interactions are with the vendor's service rather than with the public CA.

R-REDUCE-CA:

yes, it reduces interaction with public CAs but has same number of interactions with the CPE operator's CA.

R-ELIMINATE-CA: no

Name constraints have no existing support by CAs or by clients.

R-SUPPORT-CA: no

R-SUPPORT-CLIENT: no

R-REVOKE-AUTH:

Somewhat, if client retrieves CRL frequently and if CRL is updated frequently, and user has mechanism to declare the certificate as invalid.

4.4. ACME Delegated Certificates

ACME Delegated Certificates [RFC9115] allows the device to use a vendor- operated service to obtain a CA-signed ACME delegated certificate. It allows the device to request from a service managing the device -- acting as a profiled ACME server -- a certificate for a delegated identity, i.e., one belonging to the device. The device then uses the ACME protocol (with the extensions described in [RFC8739]) to request issuance of a short-term, Automatically Renewed (STAR) certificate for the same delegated identity. The generated short-term certificate is automatically renewed by the public CA, is periodically fetched by the device.

R-REDUCE-CA: No

R-ELIMINATE-CA: No

ACME delegated certificates do not require changes to client authentication libraries or operation.

R-SUPPORT-CA: Unknown

R-SUPPORT-CLIENT: yes

R-REVOKE-AUTH:

Somewhat, if client retrieves CRL frequently and if CRL is updated frequently, and user has mechanism to declare the certificate as invalid.

4.5. Raw Public Keys (RPK)

Raw public keys (RPK) [RFC7250] can be authenticated out-of-band or using trust on first use (TOFU). For a small network, this can be more appealing than a local or remote Certification Authority signing keys and dealing with certificate renewal.

R-REDUCE-CA: yes

R-ELIMINATE-CA: yes

RPKs have been supported by OpenSSL and wolfSSL since 2023 and by GnuTLS since 2019. However, RPKs are not supported by browsers or by curl.

R-SUPPORT-CA:

n/a, this system does not use Certification Authorities at all.

R-SUPPORT-CLIENT:

Some; all major libraries support RPK, but clients (browsers and curl) do not support RPK. Further, Discovery of Network-designated Resolvers (DNR) [RFC9463]) and Discovery of Designated Resolvers (DDR) [RFC9462] in verified discovery mode expect to encounter certificates and do not support RPK.

R-REVOKE-AUTH:

Yes, user can remove the raw public key from list of authorized public keys.

4.6. Self-signed Certificate

A self-signed certificate requires the client to authorize the connection, which is usually a "click OK to continue" dialog box and is a trust on first use (TOFU) solution. While it is possible the user verifies the certificate matches expectations, this seldom occurs. The certificate warnings are normalized by users which weakens security overall.

R-REDUCE-CA: yes, public CA's are not used at all.

R-ELIMINATE-CA: yes

Existing clients support self-signed certificates fairly well, but the user experience with clients is poor: some clients can't remember to trust a certificate and clicking through certificate warnings will become normalized.

Modifying self-signed certificate handling for ".local" [RFC6761] or ".internal" [I-D.davies-internal-tld] might be worth further study.

R-SUPPORT-CA:

n/a, this system does not use Certification Authories at all.

R-SUPPORT-CLIENT: Yes, but poor user experience.

R-REVOKE-AUTH:

Yes, user can remove the certificate from list of authorized certificates.

4.7. Local Certification Authority

One device within a home network would be a CA capable of signing certificates for other in-home devices. The CA in that device would be limitied to signing only certificates belonging to that home network (using Sections 4.2 or 4.3). This allows that device to sign certificates for other devices within the network such as printers, IoT devices, NAS devices, laptops, or anything else needing to be a server on the local network.

  • This feature is beyond the scope of the ADD working group but is mentioned because it was suggested during an ADD meeting.

An example of such a system is [I-D.sweet-iot-acme].

R-REDUCE-CA:

yes, it reduces interaction with public CAs but has same number of interactions with the device operator's CA for the device itself. For other devices within the home network (e.g., printers), it eliminates interaction with the vendor's CA.

R-ELIMINATE-CA: no

While technically the industry could build such a system, building such a system across the ecosystem of client operating systems would be a daunting task.

R-SUPPORT-CA: yes

R-SUPPORT-CLIENT:

yes, if the clients add the home's CA to their trust list.

R-REVOKE-AUTH:

Yes, user can update CRL on local certificate authority device, and clients can retrieve the updated CRL.

4.8. Matter

Home devices could be enrolled in [Matter] and client devices could be configured to trust Matter certificates.

R-REDUCE-CA:

yes, it reduces interaction with public CAs but has same number of interactions with the device vendor's CA to issue the Matter Device Attestation Certificate (DAC) to each device.

R-ELIMINATE-CA: no

R-SUPPORT-CA: yes

R-SUPPORT-CLIENT:

yes, if the clients add the Matter Product Attestation Intermediates (PAIs) to their trust list.

R-REVOKE-AUTH: Yes

6. IANA Considerations

This document has no IANA actions.

7. References

7.1. Normative References

[ACME]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, , <https://www.rfc-editor.org/rfc/rfc8555>.
[Matter]
Connectivity Standards Alliance, "Matter: The Foundation for Connected Things", Version 1.2, , <https://csa-iot.org/all-solutions/matter/>.
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC7250]
Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, , <https://www.rfc-editor.org/rfc/rfc7250>.
[RFC9115]
Sheffer, Y., López, D., Pastor Perales, A., and T. Fossati, "An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates", RFC 9115, DOI 10.17487/RFC9115, , <https://www.rfc-editor.org/rfc/rfc9115>.
[RFC9345]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, "Delegated Credentials for TLS and DTLS", RFC 9345, DOI 10.17487/RFC9345, , <https://www.rfc-editor.org/rfc/rfc9345>.

7.2. Informative References

[https-local-dom]
Thomson, M., "HTTPS for Local Domains", , <https://docs.google.com/document/d/170rFC91jqvpFrKIqG4K8Vox8AL4LeQXzfikBQXYPmzU>.
[I-D.davies-internal-tld]
Davies, K. and A. McConachie, "A Top-level Domain for Private Use", Work in Progress, Internet-Draft, draft-davies-internal-tld-00, , <https://datatracker.ietf.org/doc/html/draft-davies-internal-tld-00>.
[I-D.reddy-add-delegated-credentials]
Reddy.K, T., Boucadair, M., Wing, D., and S. Jain, "Delegated Credentials to Host Encrypted DNS Forwarders on CPEs", Work in Progress, Internet-Draft, draft-reddy-add-delegated-credentials-03, , <https://datatracker.ietf.org/doc/html/draft-reddy-add-delegated-credentials-03>.
[I-D.sweet-iot-acme]
Sweet, M., "ACME-Based Provisioning of IoT Devices", Work in Progress, Internet-Draft, draft-sweet-iot-acme-06, , <https://datatracker.ietf.org/doc/html/draft-sweet-iot-acme-06>.
[RFC6761]
Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, , <https://www.rfc-editor.org/rfc/rfc6761>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8555]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, , <https://www.rfc-editor.org/rfc/rfc8555>.
[RFC8739]
Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor Perales, A., and T. Fossati, "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)", RFC 8739, DOI 10.17487/RFC8739, , <https://www.rfc-editor.org/rfc/rfc8739>.
[RFC9147]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, , <https://www.rfc-editor.org/rfc/rfc9147>.
[RFC9462]
Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, "Discovery of Designated Resolvers", RFC 9462, DOI 10.17487/RFC9462, , <https://www.rfc-editor.org/rfc/rfc9462>.
[RFC9463]
Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., and T. Jensen, "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", RFC 9463, DOI 10.17487/RFC9463, , <https://www.rfc-editor.org/rfc/rfc9463>.

Appendix A. Example of Delegated Certificate Issuance

Let's consider that the customer router, needing a certificate for its HTTPS-based management, is provisioned by a service (e.g., ACS) in the operator's network. Also, let's assume that each CPE is assigned a unique FQDN (e.g., "cpe-12345.example.com" where 12345 is a unique number).

  • It is best to ensure that such an FQDN does not carry any Personally Identifiable Information (PII) or device identification details like the customer number or device's serial number.

The CPE generates a public and private key-pair, builds a certificate signing request (CSR), and sends the CSR to a service in the operator managing the CPE. Upon receipt of the CSR, the operator's service can utilize certificate management protocols like ACME [RFC8555] to automate certificate management functions such as domain validation procedure, certificate issuance, and certificate revocation.

The challenge with this technique is that the service will have to communicate with the CA to issue certificates for millions of CPEs. If an external CA is unable to issue a certificate in time or replace an expired certificate, the service would no longer be able to present a valid certificate to a CPE. When the service requests certificate issuance for a large number of subdomains (e.g., millions of CPEs), it may be treated as an attacker by the CA to overwhelm it. Furthermore, the short-lived certificates (e.g., certificates that expire after 90 days) issued by the CA will have to be renewed frequently. With short-lived certificates, there is a smaller time window to renew a certificate and, therefore, a higher risk that a CA outage will negatively affect the uptime of the encrypted DNS forwarders on CPEs (and the services offered via these CPEs).

These challenges can be addressed by using protocols like ACME to automate the certificate renewal process, ensuring certificates are renewed well before expiration. Additionally, incorporating another CA as a backup can provide redundancy and further mitigate the risk of outages. By having a secondary CA, the service can switch to the backup CA in case the primary CA is unavailable, thus maintaining continuous service availability and reducing the risk of service disruption.

It offers the additional advantage of improving the security of Browser and CPE interactions. This ensures that HTTPS access to the CPE is possible, allowing the device administrator to securely communicate with and manage the CPE.

Acknowledgments

This draft is the result of discussions at IETF119 and IETF120 in the ADD working group. Thanks to all the participants at the microphone, hallways, and mailing list.

Thanks for suggestion from Glenn Deen to adjust focus to three device classes and focus on all home servers suffering the same authentication problem.

Acknowledgements from [I-D.reddy-add-delegated-credentials]:

Thanks to Neil Cook, Martin Thomson, Tommy Pauly, Benjamin Schwartz, and Michael Richardson for the discussion and comments.

Authors' Addresses

Tirumaleswar Reddy
Nokia
Bangalore
Karnataka
India
Mohamed Boucadair
Orange
35000 Rennes
France
Dan Wing
Cloud Software Group Holdings, Inc.