]> Citrix

danwing@gmail.com

Nokia

kondtir@gmail.com

Operations and Management Area Working Group network security This document describes how a host uses the encrypted DNS server identity to reduce an attacker's capabilities if the attacker is emulating a wireless network. 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 OPSAWG Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction When a user connects to a wireless network the user or their device want to be sure the connection is to the expected network, as different networks provide different services in terms of performance, security, access to split-horizon DNS servers, and so on. Although 802.1X provides layer 2 security for both Ethernet and Wi-Fi networks, 802.1X is not widely deployed -- and often applications are unaware if the underlying network was protected with 802.1X. An attacker can operate a rogue WLAN access point with the same SSID and WPA-PSK as a victim's network . Also, there are many deployments (for example, coffee shops and bars) that offer free Wi-Fi connectivity as a customer incentive. Since these businesses are not Internet service providers, they are often unwilling and/or unqualified to perform advanced (sometimes, complex) configuration on their network. In addition, customers are generally unwilling to do complicated provisioning on their devices just to obtain free Wi-Fi. This leads to a popular deployment technique -- a network protected using a shared and public Pre-Shared Key (PSK) that is printed on a sandwich board at the entrance, on a chalkboard on the wall or on a menu. The PSK is used in a cryptographic handshake, defined in , called the "4-way handshake" to prove knowledge of the PSK and derive traffic encryption keys for bulk wireless data. The same deployement technique is typically used in residential or small office/home office networks. If the PSK for the wireless authentication is the same for all devices that connect to the same WLAN, the shared key will be available to all nodes, including attackers, so it is possible to mount an active on-path attack. This document describes how a wireless client can utilize network-advertised encrypted DNS servers to ensure that the attacker has no more visibility to the client's DNS traffic than the legitimate network. In cases where the local network provides its own encrypted DNS server, the client can even ensure it has re-connected to the same network, offering the client enough information to positively detect a significant change in the encrypted DNS server configuration -- a strong indicator of an attacker operating the network. The proposed mechanism is also useful in deployments using Opportunistic Wireless Encryption and in LTE/5G mobile networks where the long-term key in the SIM card on the UE can be compromised (Section 1 of ). The theory of operation is described mainly from the perspective of a host that connects to a network. Further interactions may be considered to seek for specific actions from a user (e.g., consent, validation). Whether and how such interactions are supported is implementation-specific and are, as such, out of scope. The document assumes that the host supports at least one encrypted DNS scheme (e.g., DNS over TLS or DNS over HTTPS). The current version of the specification focuses on wirless networks. The applicability to other network types may be assessed in future versions.

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.

Theory of Operation A host connects to a network and obtains network-related information via DHCPv4, DHCPv6, or RA. The network indicates its encrypted DNS server using either or . If the host supports an encrypted DNS scheme that is advertised by the network, the host then connects to at least one of the designated encrypted DNS servers, completes the TLS handshake, and performs public key validation of the presented certificate following conventional procedures. The host can associate the network name with the encrypted DNS server's identity that was learned via or . The type of the network name is dependent on the access technology to which the host is attached. For networks based on IEEE 802.11, the network name will be the SSID of the network and the PSK. The PSK is used along with SSID to uniquely identify the network to deal with common Wi-Fi names such as "Airport WiFi" or "Hotel WiFi" or "Guest" but are distinct networks with different PSK. The combination of SSID and PSK is useful in deployments where the same Wi-Fi name is used in many locations around the world, such as branch offices of a corporation. It is also useful in Wi-Fi deployments that have multiple Basic Service Set Identifiers (BSSIDs) where 802.11r coordinates session keys amongst access points. However, in deployments using Opportunistic Wireless Encryption, the network name will be the SSID of the network and BSSID. For 3GPP access-based networks, it is the Public Land-based Mobile Network (PLMN) Identifier of the access network, and for 3GPP2 access, the network name is the Access-Network Identifier (see ). If DDR is used for discovery, the host would have to perform verified discovery as per Section 4.2 of and the encrypted DNS server identity will be the encrypted DNS server's IP address. If DNR is used, the encrypted DNS server identity will be the Authentication Domain Name (ADN). If this is the first time the host connects to that encrypted DNS server, the hosts follows or validation procedures, which will authenticate and authorize that encrypted DNS server's identity. Better authentication can be performed by verifying the encrypted DNS server's certificate with the identity provided in an extended Wi-Fi QR code (), consulting a crowd-sourced database, reputation system, or -- perhaps best -- using a matching SSID and SubjectAltName described in . After this step, the relationship of SSID, PSK, encrypted resolver discovery mechanism, and SubjectAltName are stored on the host. For illustrative purposes, provides an example of the data stored for two Wi-Fi networks, "Example WiFi 1" and "Example WiFi 2" (showing hashed PSK),

An Example of Data Stored for Two WiFi Networks

For illustrative purposes, provides an example of the data stored for two 3GPP2 networks,

An Example of Data Stored for Two 3GPP2 Networks

If this is not the first time the host connects to this same SSID, then the Wi-Fi network name, PSK identifier, encrypted resolver disovery mechanism, and encrypted DNS server's identity should all match for this re-connection. If the encrypted DNS server's identity differs, this indicates a different network than expected -- either a different network (that happens to also use the same SSID), change of the network's encrypted DNS server identity, or an Evil Twin attack. The host and/or the user can then take appropriate actions. Additionally, in a mobile network, the UE can send the discovered encrypted resolver's identity securely to the Mobile Core Network to assist it in identifying compromised base stations . It complements existing techniques used to identify fake base stations.

Avoiding Trust on First Use Trust on First Use can be avoided if the SSID name and DNS server's Subject Alt Name match. Unfortunately such a constraint disallows vanity SSID names. Also, social engineering attacks gain additional information if the network's physical address (123-Main-Street.example.net) or name (John-Jones.example.net) is included as part of the SSID. Thus the only safe SSID name provides no information to assist social engineering attacks such as a customer number (customer-123.example.net), assuming the customer number can safely be disclosed to neighbors. Such attacks are not a concern in deployments where the network name purposefully includes the business name or address (e.g., Public WiFi hotspots; 123-Main-Street.example.com, coffee-bar.example.com). The Extensible Authentication Protocol (EAP), defined in , provides a standard mechanism for support of multiple authentication methods. EAP-TLS specifies an EAP authentication method with certificate-based mutual authentication utilizing the TLS handshake protocol for cryptographic algorithms and protocol version negotiation and establishment of shared secret keying material. Many other EAP methods such as Flexible Authentication via Secure Tunneling (EAP- FAST) , Tunneled Transport Layer Security (EAP-TTLS) , the Tunnel Extensible Authentication Protocol (TEAP) , as well as vendor-specific EAP methods such as the Protected Extensible Authentication Protocol (PEAP) [PEAP], depend on TLS and EAP-TLS. In networks that use the EAP-TLS method or an EAP method that depends on TLS, if the SSID name matches one of the subjectAltName entries in the EAP-TLS server certificate, Trust on First Use can be avoided. It is especially useful in deployments where the endpoint is not managed using an MDM. For instance, it can be used during the device registration process (e.g., using Over-The-Air (OTA) enrollment [OTA] to provision the device with a certificate and configuration profile) or in networks (e.g., emergency services as discussed in Section 2.1.5 of ) where client authentication is not required or in networks that use password to authorize the client to access the network (e.g., using password authenticated key exchange with TLS).

Security Considerations The network-designated resolver may or may not be local to the network. DDR is useful in deployments where the local network cannot be upgraded to host a encrypted resolver and the CPE cannot be upgraded to support DNR. For example, DDR is typically used to discover the ISP's encrypted resolver or a public encrypted resolver. The encrypted resolver discovered using DNR may be a public encrypted resolver or hosted by the local network or by the ISP. The mechanism specified in this document does not assist the client to identity if the network-designated resolver is hosted by the local network. However, it significantly reduces the attacker's capabilities if the attacker is emulating a network (that is, operating a look-alike network). More and more content delivery networks, sensitive domains and endpoints are migrating to TLS 1.3 and ECH. If the attacker's network conveys the same encrypted revolver's identity as the legitimate network, it will not have any visibility into the private and sensitive information about the target domain. However, the attacker's network will still have visibility into the traffic metadata like the destination IP address, sequence of packet lengths, inter- arrival times, etc. The network authentication mechanism relies upon an attacker's inability to obtain an application PKI certificate for the victim's configured encrypted DNS server. Neither a plain-text PSK nor hash of the PSK is necessary for the mechanism described in this document; rather, an implementation can use a key identifier.

IANA Considerations This document has no IANA actions.

References Normative References Orange Nokia Citrix Systems, Inc. Open-Xchange Microsoft The document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over- TLS, DNS-over-QUIC). Particularly, it allows a host to learn an authentication domain name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. Apple Inc. Apple Inc. Cloudflare Fastly Microsoft This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An encrypted DNS resolver discovered in this manner is referred to as a "Designated Resolver". This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. This mechanism is designed to be limited to cases where unencrypted DNS resolvers and their designated resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an encrypted DNS resolver is known. 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 This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media. This document specifies the format and mechanism that is to be used for encoding Access-Network Identifiers in DHCPv4 and DHCPv6 messages by defining new Access-Network-Identifier options and sub-options. This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK] The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK] This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. This memo provides information for the Internet community. EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information for the Internet community. This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. Ericsson Ericsson Ericsson Ericsson Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles. This specification updates RFC 9048, the EAP-AKA' authentication method, with an optional extension. Similarly, this specification also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP- AKA'. This prevents an attacker who has gained access to the long- term pre-shared secret in a SIM card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead.

Extending WiFi QR Code This section is non-normative and merely explains how extending the Wi-Fi QR code could work. QR codes come with their own security risks, most signficant that an attacker can place their own QR code over a legitimate QR code. Several major smartphone operating systems support a QR code with the following format for the SSID "example" with WPA-PSK "password", This could be extended to add a field containing the identity of the encrypted DNS server. As several DNS servers can be included in the QR code with "D:", each DNS server with its own identity using line folding,

Acknowledgments This document was inspired by both Paul Wouters and Tommy Pauly during review of other documents. Thanks to Mohamed Boucadair for the review.