Asserting Wireless Network Connections Using DNS Revolvers' Identities
Internet-Draft draft-wing-opsawg-authenticating-network-00
Dan Wing
Citrix
danwing@gmail.com
Tirumaleswar Reddy
Nokia
kondtir@gmail.com
22 September 2022
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 https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-wing-opsawg-authenticating-network/.
Discussion of this document takes place on the OPSAWG Working Group mailing list (mailto:opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Subscribe at https://www.ietf.org/mailman/listinfo/opsawg/.
Source for this draft and an issue tracker can be found at https://github.com/danwing/authenticating-network.
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 [Evil-Twin]. 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 [IEEE802.11], 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 [RFC8110] and in LTE/5G mobile networks where the long-term key in the SIM card on the UE can be compromised (Section 1 of [AKA]).
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 [RFC2119] [RFC8174] 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 [DNR] or [DDR]. 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 [DNR] or [DDR]. 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 [RFC7839]).
If DDR is used for discovery, the host would have to perform verified discovery as per Section 4.2 of [DDR] 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 [DNR] or [DDR] 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 (Appendix A), consulting a crowd-sourced database, reputation system, or -- perhaps best -- using a matching SSID and SubjectAltName described in Section 4.
After this step, the relationship of SSID, PSK, encrypted resolver discovery mechanism, and SubjectAltName are stored on the host.
For illustrative purposes, Figure 1 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

{
  "networks": [
    {
      "SSID": "Example WiFi 1",
      "PSK-ID": 12,
      "Discovery": "DNR",
      "Encrypted DNS": "resolver1.example.com"
    },
    {
      "SSID": "Example WiFi 2",
      "PSK-ID": 42,
      "Discovery": "DDR",
      "Encrypted DNS": [
           "8.8.8.8",
           "1.1.1.1"
      ]
    }
  ]
}

For illustrative purposes, Figure 2 provides an example of the data stored for two 3GPP2 networks,
An Example of Data Stored for Two 3GPP2 Networks

{
  "networks": [
    {
      "realm": "ims.mnc015.mcc234.3gppnetwork.org",
      "Discovery": "DNR",
      "Encrypted DNS": "resolver2.example.com"
    },
    {
      "realm": "ims.mnc016.mcc235.3gppnetwork.org",
      "Discovery": "DDR",
      "Encrypted DNS": [
           "8.8.8.8",
           "1.1.1.1"
      ]
    }
  ]
}

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 [NIST.SP.800-187]. It complements existing techniques [TR33.809] 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).
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
[DNR]

DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)
Mohamed Boucadair
Orange
Tirumaleswar Reddy
Nokia
Dan Wing
Citrix Systems, Inc.
Neil Cook
Open-Xchange
Tommy Jensen
Microsoft
13 August 2022
Internet-Draft draft-ietf-add-dnr-13
[DDR]

Discovery of Designated Resolvers
Tommy Pauly
Apple Inc.
Eric Kinnear
Apple Inc.
Christopher A. Wood
Cloudflare
Patrick McManus
Fastly
Tommy Jensen
Microsoft
5 August 2022
Internet-Draft draft-ietf-add-ddr-10
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[Evil-Twin]

Evil twin (wireless networks)
Wikipedia
June 2022
[IEEE802.11]

IEEE802.11
Wikipedia
August 2022
[TR33.809]

Study on 5G Security Enhancement against False Base Stations
3GPP
June 2022
[NIST.SP.800-187]

Guide to LTE Security
NIST
December 2017
[RFC8792]

Handling Long Lines in Content of Internet-Drafts and RFCs
K. Watsen
E. Auerswald
A. Farrel
Q. Wu
June 2020
RFC 8792
DOI 10.17487/RFC8792
[RFC8110]

Opportunistic Wireless Encryption
D. Harkins, Ed.
W. Kumari, Ed.
March 2017
RFC 8110
DOI 10.17487/RFC8110
[RFC7839]

Access-Network-Identifier Option in DHCP
S. Bhandari
S. Gundavelli
M. Grayson
B. Volz
J. Korhonen
June 2016
RFC 7839
DOI 10.17487/RFC7839
[AKA]

Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)
Jari Arkko
Ericsson
Karl Norrman
Ericsson
Vesa Torvinen
Ericsson
John Mattsson
Ericsson
11 July 2022
Internet-Draft draft-ietf-emu-aka-pfs-07
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",

  WIFI:T:WPA;S:example;P: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 [RFC8792] line folding,

=============== NOTE: '\' line wrapping per RFC 8792 ================

  WIFI:T:WPA;S:example;P:password; \
  D:ns1.example.net,D:ns.example.com;;

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