Identifying and Authenticating Home Servers: Requirements and Solution Analysis
draft-rbw-home-servers-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Mohamed Boucadair , Dan Wing | ||
| Last updated | 2024-09-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rbw-home-servers-00
network T. Reddy
Internet-Draft Nokia
Intended status: Informational M. Boucadair
Expires: 23 March 2025 Orange
D. Wing
Cloud Software Group
19 September 2024
Identifying and Authenticating Home Servers: Requirements and Solution
Analysis
draft-rbw-home-servers-00
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.
Reddy, et al. Expires 23 March 2025 [Page 1]
Internet-Draft Home Servers September 2024
Copyright Notice
Copyright (c) 2024 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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Reduce Use of Public Certification Authority . . . . . . 3
3.2. Eliminate Use of Public Certification Authority . . . . . 4
3.3. Existing Support by Certification Authorities . . . . . . 4
3.4. Client Support . . . . . . . . . . . . . . . . . . . . . 4
3.5. Revoke Authorization . . . . . . . . . . . . . . . . . . 5
4. Analysis of Solutions to Requirements . . . . . . . . . . . . 5
4.1. Normal Certificates . . . . . . . . . . . . . . . . . . . 6
4.2. Delegated Credentials . . . . . . . . . . . . . . . . . . 7
4.3. Name Constraints . . . . . . . . . . . . . . . . . . . . 8
4.4. ACME Delegated Certificates . . . . . . . . . . . . . . . 8
4.5. Raw Public Keys (RPK) . . . . . . . . . . . . . . . . . . 9
4.6. Self-signed Certificate . . . . . . . . . . . . . . . . . 9
4.7. Local Certification Authority . . . . . . . . . . . . . . 10
4.8. Matter . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Example of Delegated Certificate Issuance . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Reddy, et al. Expires 23 March 2025 [Page 2]
Internet-Draft Home Servers September 2024
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:
Reddy, et al. Expires 23 March 2025 [Page 3]
Internet-Draft Home Servers September 2024
* 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.
Reddy, et al. Expires 23 March 2025 [Page 4]
Internet-Draft Home Servers September 2024
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.
Reddy, et al. Expires 23 March 2025 [Page 5]
Internet-Draft Home Servers September 2024
+===============+========+===========+==========+============+======+
| Solution | Reduce | Eliminate | Existing | Existing |Revoke|
| | CA | CA | CA | Client | Auth |
| | | | Support | Support | |
+===============+========+===========+==========+============+======+
| Normal | No | No | Yes | Yes | Some |
| certificates | | | | | |
+---------------+--------+-----------+----------+------------+------+
| Delegated | Yes, | No | No | No, (*) | Some |
| credentials |somewhat| | | | |
+---------------+--------+-----------+----------+------------+------+
| Name | Yes | No | No | No | Some |
| constraints | | | | | |
+---------------+--------+-----------+----------+------------+------+
| ACME | No | No | Yes | Yes | Some |
| delegated | | | | | |
| certificates | | | | | |
+---------------+--------+-----------+----------+------------+------+
| Raw Public | Yes | Yes | n/a | Some, (*) | Yes |
| Keys | | | | | |
+---------------+--------+-----------+----------+------------+------+
| Self-Signed | Yes | Yes | n/a | Yes, poor | Yes |
| Certificate | | | | experience | |
+---------------+--------+-----------+----------+------------+------+
| Local | No | No | Yes | Yes | Yes |
| Certification | | | | | |
| Authority | | | | | |
+---------------+--------+-----------+----------+------------+------+
| Matter | Yes | No | Yes | Yes | Yes |
+---------------+--------+-----------+----------+------------+------+
Table 1: Summary of Solution Analysis
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
Reddy, et al. Expires 23 March 2025 [Page 6]
Internet-Draft Home Servers September 2024
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
Reddy, et al. Expires 23 March 2025 [Page 7]
Internet-Draft Home Servers September 2024
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
Reddy, et al. Expires 23 March 2025 [Page 8]
Internet-Draft Home Servers September 2024
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.
Reddy, et al. Expires 23 March 2025 [Page 9]
Internet-Draft Home Servers September 2024
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.
Reddy, et al. Expires 23 March 2025 [Page 10]
Internet-Draft Home Servers September 2024
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
5. Security Considerations
TBD.
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, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
[Matter] Connectivity Standards Alliance, "Matter: The Foundation
for Connected Things", Version 1.2, October 2023,
<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, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
Reddy, et al. Expires 23 March 2025 [Page 11]
Internet-Draft Home Servers September 2024
[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,
June 2014, <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, September 2021,
<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, July 2023,
<https://www.rfc-editor.org/rfc/rfc9345>.
7.2. Informative References
[https-local-dom]
Thomson, M., "HTTPS for Local Domains", April 2021,
<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, 2 August 2024,
<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, 1 December 2023,
<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, 9
August 2024, <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, February 2013,
<https://www.rfc-editor.org/rfc/rfc6761>.
Reddy, et al. Expires 23 March 2025 [Page 12]
Internet-Draft Home Servers September 2024
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<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, March 2019,
<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, March 2020,
<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, April 2022,
<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, November 2023,
<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, November 2023,
<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.
Reddy, et al. Expires 23 March 2025 [Page 13]
Internet-Draft Home Servers September 2024
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.
Reddy, et al. Expires 23 March 2025 [Page 14]
Internet-Draft Home Servers September 2024
Authors' Addresses
Tirumaleswar Reddy
Nokia
Bangalore
Karnataka
India
Email: kondtir@gmail.com
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Dan Wing
Cloud Software Group Holdings, Inc.
Email: danwing@gmail.com
Reddy, et al. Expires 23 March 2025 [Page 15]