]> Cloud Software Group, Inc.

danwing@gmail.com

Akamai Technologies

erik+ietf@nygren.org http://erik.nygren.org/

Sandelman Software Works

mcr+ietf@sandelman.ca

https local domains pki pkix certificate authority tls identity authentication When connecting to servers on their local network, users are surprised to encounter user interfaces that display errors, show insecure connections, and block some HTTP features when missing a secure context. However, obtaining PKIX certificates for those servers is difficult for a variety of reasons. This document explores requirements for authenticating local servers. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the SETTLE mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Servers on local networks have historically settled for unencrypted communications -- printers, routers, network attached storage (NAS). However, with the advent of HTTPS everywhere , browsers disadvantage unencrypted communications (e.g., , ). This increases importance of a secure context (HTTPS) to local domains. In addition, it is recognized that home networks are not (and perhaps have never been) the idyllic secure gardens that many think they are. There are persistent threats in the home due to malware on devices within the home, as well as malware that might arrive on guest devices. Most home networks have little protection against various kinds of (layer-2) spoofing attacks, which means that active on-path attacks (MITM) must be assumed. Securing the administrative and regular connections within the home network would result in significant security gains for all devices in the home. Today, a secure context is obtained with a PKIX certificate () signed by a Certification Authority (CA) that is trusted by the client. However, servers on a local network cannot easily get PKIX certificates signed by a Certification Authority because: they are not directly reachable from the outside (due to firewall or NAPT), lack of domain name delegation, and need for ongoing certificate renewal. The problem has been well recognized since about 2010 and several proposals have been suggested to solve this problem, each with their own drawbacks. This document is not intended to summarize these proposals or their drawbacks; for that detail see the pointers to previous work in . At a high level, the proposals have involved solutions such as:

• pre-shared secrets (scanned, printed, or displayed by the server)
• Public DNS pointing at local domain's IP address (e.g., )
• Local Certification Authority, where a CA is added to client's certificate trust list and that CA signs certificates for devices within the local network
• Trust On First Use (TOFU), where a user verifies the first connection to a server and the client remembers that verification, similar to common use of ssh
• WebRTC and WebTransport, where a PKI-signed server provides a public key fingerprint of another server that it has previously bootstrapped
• Encoding server's public key into the hostname

This document explores IETF requirements for an alternative server authentication system for local hosts.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Technical Requirements The goal is to work out the engineering tradeoff around . Specifically it says there are three aspects that must be traded off:

• Human-meaningful
• Secure
• Decentralized

Naming PKIX certificates are a centralized naming scheme derived from DNS. These names have (the possibility of) having human-readable names. But the most significant property is uniqueness -- each name has its own identity and that identity can be proven. A system that does not rely on centralized naming lacks this inherient uniqueness property. Name collisions can be engineered by attackers for nefarious purposes. For example, if a victim is configured to use the (likely) unique name "printer-12ab34cd56ef.local" (containing the printer's full or partial MAC address), an attacker can respond to connections to that name, potentially stealing the user's authentication credentials to that printer or seeing the content the user sent to that printer. Similar attacks are possible with file shares. This problem is exacerbated if non-unique names are used (e.g., simply "printer.local" or "router.local"), as it reduces the attacker's effort. Humans prefer simple, human-readable names, but a strong identity cannot be created with such names.

• R-UNIQUE-NAME: The system MUST have a way to uniquely identify servers.

Cryptographic Binding A server's name has to be mapped to its cryptographic identity.

• R-BINDING: The Web Origin MUST be cryptographically bound to one or more key pairs, where the private keying material is on the service endpoint and where an attacker without the private key(s) is unable to access any state associated with the Web Origin.

A client has to be able to validate the name maps to the cryptographic identity.

• R-VALIDATE: Clients MUST be able to cryptographically validate that the authenticating server matches the identity in the URI / Web Origin.

Web browsers and modern users both expect a URI.

• R-URI: It MUST be possible to construct a URI that encapsulates a Web Origin and its cryptographically-bound identity information.

Abstract Naming Using IP addresses in names is problematic if the server's IP address changes due to ISP renumbering or internal network DHCP server reconfiguration. Given common NAT44 (NAPT), many many networks will share the same IPv4 addresses.

• R-ABSTRACT: The solution SHOULD abstract names from IP addresses.

Any given name should be resolvable to a mixture of IPv4, IPv6 Link-Local (on an Interface), IPv6 ULA, and IPv6 Globally-Routable addresses. Operating a local DNS is beyond the scope of many administrators, so being able to advertise the server using is necessary.

• R-DNS-SD: The name MUST be advertisable using

Avoid Central Authority A solution needs to be self-contained and not use the central authority of PKIX. Being self-contained also removes reliance on a device vendor (to operate a centralized service).

• R-AVOID-CENTRAL: A solution MUST NOT rely on central trust hierarchy.

Vendors go out of business or lose interest in continuing to service old products. The products may still be operational.

• R-AVOID-VENDOR: A solution SHOULD NOT (MUST NOT?) have continued reliance on a service operated by a vendor, including if the device is reset to factory defaults (e.g., reset for troubleshotting or because sold).

Multiple Application Protocols A solution has to support HTTPS because it is frequently used for device management.

• R-HTTPS: A solution MUST support HTTPS.

Other encrypted protocols are also frequently used on local networks for DNS, file sharing, mail, and telephony.

• R-MULT-APP: A solution SHOULD support other application-level protocols such as DoT , SMB over QUIC , IMAP , and SIP , as those protocols are routinely served within a local domain.

Cryptographic Agility A solution has to support moving to new cryptographic functions.

• R-AGILITY: A solution SHOULD support cryptographic agility (such as supporting more than one active key type and different hashes).

TLS Server Name Indication TLS servers frequently use the TLS SNI extension to support multiple identities on a single server.

• R-TLS-SNI: A solution SHOULD support TLS SNI so a server knows which key pair/cert is expected.

W3C Private Network Access To prevent various attacks, W3C has constrained how browsers operate on private networks

• R-PNA: A solution SHOULD integrate well with an evolution of and both allow for an improved model there but should also provide more robust solutions to vulnerabilities that it tries to address

Operate with Local Resources The TLDs ".local" and ".internal" are defined local domains and enterprise networks usually have a site domain ("internal.example.com"). A solution that scales from a home network to an enterprise network is desirable.

• R-LOCAL: A solution MUST operate with .local and .internal, and SHOULD operate with an administratively-defined zone (e.g., internal.example.com).

• Discuss: MAY constrain to the DHCP domain-search value?? Should we also allow any arbitrary name if the IP address is local (RFC1918 address), too?

Operate Standalone The system needs to operate without a connection to the Internet. This is necessary because Internet connectivity is sometimes flaky or unavailable (e.g., cabin in the woods, lengthy ISP outage).

• R-STANDALONE: MUST NOT require Internet connectivity to operate securely, for its initial configuration, or to add or remove a device from list of authorized devices in the system.

• Discuss: perhaps want to refine wording of this requirement, or split into separate requirements.

Web Origin The Web Origin is comprised of the scheme (e.g., "https:"), hostname, and port. Today, when a key rotation occurs the Web Origin remains the same. In this way, things like stored web data (forms, passwords, cookies) can be used even after a key rotation.

• R-WEB-ORIGIN: The Web Origin MUST be retained during key rotation.

Miscellaneous

1. It SHOULD be possible to have a way to represent a URI that includes a single specific IP address and the cryptographic identity of the service endpoint.

• Discuss: the above requirement needs to be re-written.

1. SHOULD support key rotation (even if via 301 redirect)

• Q: is it acceptable to state to be lost here? Note: likely cannot do 301 if doing TLS (HTTPS). Is this suggestion to start HTTP and upgrade to HTTPS? Could be useful for HTTPS but redirect unavailable for IPP, SMB, DoH.

• Discuss: the above requirement needs to be re-written.

1. SHOULD support building trust relationships within devices in the local environment

• Discuss: the above requirement needs to be re-written.

1. Could this help with HTTPS access to Wi-Fi login portals (, )?

• Discuss: the above requirement needs to be re-written.

Human Factors Requirements

Discoverable Most local networks, especially home networks, do not operate their own DNS server. Many clients already support listening for DNS-SD broadcasts.

• R-DISCOVER: A solution SHOULD have a way to do discovery of endpoints and their identities (for example, via ).

Easy to Use Successful solutions are usually also easy to deploy.

• R-EASY: A solution SHOULD have human factors and adversarial testing on proposed solutions to make sure that this solution provides a reasonable experience to average and novice end-users and does not introduce new security exploitation vectors

Bookmarkable Names (or aliases to those names) should be simple for users -- ideally, user-defined so that if the underlying name is complex the user can create an alias that is meaningful to them.

• R-BOOKMARK: A solution SHOULD have a URI that users can Bookmark to create an association to a friendly name.

• Discussion: Can URL bar of the browser honor mDNS/DNSSD advertised names, or give a pull-down of them similar to how the "add printer" dialog does for printers? This would help ease the use of long FQDN so it's almost as easy as router.local. Especially if it could show a nickname that is configured by the printer. Browser extensions exist for DNS-SD and mDNS (, ).

Human-friendly Name Names (or aliases to those names) should be simple for users -- ideally, user-defined so that if the underlying name is complex the user can create an alias that is meaningful to them.

• R-CONSISTENT: A solution SHOULD represent these URIs to humans in a consistent, readable, and non-confusing fashion. (In a browser, users shouldn't see the key fingerprint by default but rather a representation of its presence)

Big Open Questions

Trust on First Use (TOFU) As evidenced by web browser behavior over the years with self-signed certificates and their (increased) warnings, TOFU will not be acceptable.

User Experience For a solution, what is the User Experience for any trust relationship / web-of-trust?

Trust Relationship For a solution, what is the nature of the trust relationship?

• Peer trust web?
• Central CA within the local environment / trust clearing house?
• Client establishes its own trust to the server

Interaction with Matter/Thread How does a solution tie into systems like Matter/Thread that have their own trust establishment frameworks?

Use Cases For the below, "Secure communications" means being able to make a TLS connection to a service such that the service is able to authenticate itself in a way to prevent MitM attacks. The security model must be TOFU at a minimum, but when the identity of a service is none it should be possible to send it as a URI in such as a way to present a secure association rooted in the connection that sent it:

• Secure communications via HTTPS to admin interfaces on CPEs for both initial and ongoing configuration tasks of various servers (router, printer, NAS, etc.).
• Secure communications to DoH/DoT servers on CPEs
• Secure communications to printers (IPPS printing)
• Secure communications to other local services (SMB over QUIC to another workstation or a NAS) and IoT devices
• Secure communications to localhost processes from a browser (e.g., admin tools)

Related Work Martin Thomson wrote HTTPS for Local Domains which covers requirements, discusses several solutions and their tradeoffs, and suggests a solution where the client extends the Web Origin to include the server's public key. It does not allow the server to rotate its public key as that would change the extended Web Origin (see ). Dan Wing has proposed a Referee system which uses a new HTTPS-based server to authorize servers public keys (akin to an allowlist or to OCSP stapling) and encoding the server's public key into its hostname. Like , it does not allow a server to rotate its key (see ). Michael Sweet has proposed a locally-deployed Certification Authority that can be incrementally deployed. W3C worked on this problem from 2017 through 2021 . More recently, W3C had a workshop on the problem in September 2024 . W3C has a working draft on OpenScreen Network Protocol which establish trust between devices for the purposes of media casting and remote presentation using DNS-SD, TLS for an initial unauthenticated connection, SPAKE2 to validate mutual identity and exchange certificates. W3C WICG also has a working draft on Peer-to-Peer API that layers a web API on top of the OpenScreen Network Protocol to allow local communication between browsers without the aid of a server. It contains proposed APIs for the following on a local network: peer advertising, peer discovery and authentication, and establishing a WebTransport. The boundaries of a limited domain -- such as the local domain described in this document -- are explored in . The IOTOPS working group and the associated IOT Security Foundation discussed the problem and some requirements in their white paper and presentation to IOTOPS working group at IETF112 . A threshold key system is described and implemented at with the following description:

• The Mesh is designed to provide users with the highest level of security that is possible without asking them to do anything at all. For this to become possible, the Mesh will have to be shipped to users as part of the machine Operating System.

A summary of the problem and analysis of several solutions (Locally-installed CAs, Plex, WebRTC and WebTransport, TOFU, shared secrets) and some drawbacks of those solutions is at . A method using PAKE and a shared secret (displayed on the server) is explained at .

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References W3C Wikipedia Presentation of IOT Security Foundation SUIB to IETF112 IOTOPS working group IOT Security Foundation W3C W3C W3C W3C Google Microsoft EFF W3C W3C WICG This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501, 5068, 6186, and 6409. This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK] This document describes a captive portal architecture. Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution. In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions. This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document. This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679. This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service. This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510. Citrix Obtaining and maintaining PKI certificates for devices in a local domain network is difficult for both technical and human factors reasons. This document describes an alternative approach to securely identify and authenticate servers in the local domain using a HTTPS- based trust anchor system, called a Referee. The Referee allows bootstrapping a network of devices by trusting only the Referee trust anchor in the local domain. Lakeside Robotics Corporation This document extends the Automatic Certificate Management Environment (ACME) 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. There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.

Change History

Changes in -01

• Changed to 2010 (from 2017) when the problem of local domain authentication was first discussed.
• Rather than simple name collision ("printer.local"), discuss how most products include the device's (partial) MAC address -- which does help distinguishing devices on different networks. Also explain how an attacker can use that name.
• R-AVOID-CENTRAL changed from SHOULD to MUST.
• Justification text added to almost all R- requirements.
• Removed R-LOCALHOST, which had said "localhost" should be handled same as a local domain. This was removed because localhost is not a unique name causing other problems for a solution.
• R-LOCAL expanded to also cover administratively-defined zone (e.g., internal.example.com)
• Refined R-STANDALONE.
• Added R-WEB-ORIGIN, and moved key rotation requirement into R-WEB-ORIGIN to say the web origin has to stay the same if the key is rotated.
• Declared TOFU as unacceptable (was a question).
• As Related Work, added: Referee, locally-deployed CA, W3C OpenScreen Network Protocol, W3C WICG Peer-to-Peer API.
• Added pointers to DNS-SD and mDNS extensions for web browsers.

Acknowledgments Thanks to Michael Sweet for his review and feedback. Thanks to Michiel De Backker for references to related W3C work.