Use Cases and Requirements on HTTPS-enabled Local Network Servers

Draft Community Group Report,

This version:
https://httpslocal.github.io/usecases/
Issue Tracking:
GitHub
Editor:
Contributors on GitHub

Abstract

This document describes use cases of HTTPS-enabled local network servers and requirements for their HTTPS deployment.

Status of this document

This specification was published by the HTTPS in Local Network Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

1. Introduction

This document describes use cases where browsers communicate with web-server-capable devices in local network via HTTP (https://) and/or WebSocket over TLS (wss://), as well as network, security, and privacy requirements on these usage.

Nowadays, a lot of devices like Internet-of-Things (IoT) devices and home gateways often have their own built-in HTTP server so that they can provide interfaces to configure and/or control them remotely via IPv4/IPv6 local network. Modern web browsers, however, usually regard those local servers as not trustworthy due to lack of authenticity of device’s identity. As a result, browsers would prevent trustworthy web sites from communicating to local network devices [MIXED-CONTENT] and prohibit web pages on the servers from accessing powerful features on browsers [SECURE-CONTEXTS].

Therefore, this document illustrates potential use cases that need access to local network servers and clarifies requirements for use of these servers.

2. Use cases

2.1. UC-01: Playing audio content in a home storage device from a cloud service

Users can store their audio contents in their storage device, or set-top boxes, in their home. They access online music web services with web browsers, and use a music player implemented as a web application in the web services to play music stored in their home network. The music player send metadata of the music to the web service, to recommend another music content.

2.2. UC-02: Video streaming with cache storage in local network

A user has a video cache storage server for home to enjoy online video streaming services at UHDTV quality. When she opens the web site of one of the streaming services on her TV browser, the web page tries to find her cache storage and displays a list of storages via a popup window. She picks up one storage from the list to store caches of UHDTV video stream segments. After her permission, the streaming web application of the service can start prefetching or fetching UHDTV movies purchased or bookmarked by her and upload those segments to the storage. When she wants to watch one of the movies cached in the storage, the online service fetches the movie from the home storage to avoid consuming WAN traffic, and finally she can comfortably enjoy the movie.

2.3. UC-03: Web-based UI for home appliances (input/output constrained devices)

A user controls home appliances (e.g. air conditioner, microwave oven, refrigerator) with an online GUI service on the internet. The home appliances are designed natively to be used via the online GUI loaded in a browser on her smartphone or tablet. As with the use cases mentioned above, when she signs in to the online service, the service finds a home appliance through the browser. Under her approval, the service can be granted access privileges for the appliance and she can control it through the GUI service.

2.4. UC-04: Embedded system monitoring and controlling for display-capable devices

A field engineer of a digital signage service provider sets up an internet-capable display device. The engineer makes the device display a specific website as a signage content by using a browser on the device. After that, the website is monitoring the status of the embedded system (e.g. collecting logs, monitoring system resource utilization) continuously via the browser by using internal REST APIs provided by an internal web server (e.g. https://localhost) of the device. If the device provides the website with reboot functionality as one of the REST APIs, the service provider is able to not only check the health of the device, if necessary, but also reboot the device remotely via the website. This use case is about Network based API described in NetworkedBasedAPI.md

2.5. UC-05: Data analysis from analytical and measuring instruments in local network

An analytical and measuring instrument in local network outputs a large amount of raw data as the result of an experiment. An experimenter (a user of the instrument) signs in to a web-based analytical service provided by the vender of the instrument by using a browser in her PC. The experimenter analyzes the raw data by using the web service and the service fetches the raw data from the instrument directly in local network.

2.6. UC-06: Photo sharing between online services and home NAS devices

A user usually stores her private photos and videos in a home NAS device. She opens an online photo sharing service in a browser on her smartphone. The online service finds her home NAS device through the browser and shows her the NAS via a popup window. She selects the NAS and the browser shows her private photos in the NAS as well as the ones already stored in the online service. She then selects and posts some photos that she would like to share with her friends or, if she usually posts photos to the online service from her smartphone directly, she downloads the photos and posts them to the NAS device.

2.7. UC-07: Secure offline communication for home automation

A user wants to set up a new home device (e.g., a Wi-Fi access point/router, home automation gateway) in his/her home via its web interface. User typically opens a given URL for the device (e.g., https://home-router.local, or https://192.168.1.1) in a laptop or smart phone’s web browser. Since the new device does not have a valid web PKI certificate, the web browser displays a warning like “The connection is not secure” but provides an option to ask the user to approve the access or add the URL as an exception to the whitelist. Once user takes the action, the web browser treats the device as a trusted one and does not display the warning in subsequent attempts. Additionally, if the home device supports functionality such as, SSO (Single Sign-On) the user can use an identity (ID) provider’s account (e.g., Google, Facebook, and so on) to sign in the device’s web interface and provide the needed trust.

Similar secure access is required when a home gateway, which is typically controlling other home devices (e.g., door locks, security cameras), uses HTTPS for securely accepting commands via a remote server. However, when a home gateway happens to get temporarily disconnected from the internet, those home devices become inaccessible. In such scenarios, a local HTTPS communication from user’s local device (e.g., smart phone or a control device) is essential to control and operate the home devices directly through HTTPS connections over the local network.

2.8. UC-08: Companion Device for Broadcast Interactive Service

A user is watching a broadcast interactive service which is enhanced by a broadcaster’s web app running on the user agent of TV. The user hands a companion device, e.g. Smartphone, and launches a user agent with the Frontend page from the broadcaster web server. The Frontend page discovers the user-agent of TV and securely communicates with the broadcaster’s web application via the Web Socket Server on TV in order to provide GUI for the interactive broadcast service. Note that this use case is similar to the 2-UA of the Presentation API but the difference is that the broadcaster’s web application on TV is running on UA of TV in advance.

2.9. UC-09: Presenting with Projector at office

A user is attending a meeting at office (outside home). The user logs on an online document sharing service on PC and present his document file on the service with the Projector connected via local network. FrontEnd page on UA1 at PC initiates to launch 2nd frontend page on 2nd UA at the projector to let the 2nd frontend page present the document. Note that this use case is similar to 2-UA of Presentation API but the communication between 2-UA should be secured to prevent the MITM attack in the local network and also the regular WebSocket API is used for the communication, e.g. file transfer.

3. Requirements

This section outlines functional and non-functional requirements of HTTPS/WSS usage in local network represented in §2 Use cases.

Functional requirements consist of guarantee of device trustworthiness, device identification, alerting user and user consent, device discovery, and certificate management.

Non-functional requirements address security, privacy, availability, scalability, and user experience aspects of HTTPS/WSS usage in local network.

3.1. Terminology

A user agent (UA) is a web browser on a user’s PC, smartphone, tablet and so on, which is connected to a local network.

A device is in the same local network as the UA, capable of HTTPS/WSS server.

A web service is a service hosted on the internet and whose frontend is loaded on the UA, which accesses to the device with HTTPS or WSS on the local network.

A Web PKI certificate is a TLS server certificate that can chain up to a root CA (Certificate Authority) trusted by the UA (preinstalled on the UA).

A non-Web PKI certificate is a TLS server certificate that cannot chain up to a root CA, or a self-signed certificate.

A CA (merely called CA in this document) is a CA responsible for issuing the Web PKI certificates or non-Web PKI certificates. It is not restricted to a CA responsible only for issuing the Web PKI certificates.

A private CA is a CA responsible for issuing the non-Web PKI certificates.

3.2. Functional Requirements

The functional requirements are listed below:

In the following, we elaborate on individual requirements as mentioned above.

3.2.1. Guarantee of Device Trustworthiness

The UA accesses the device with TLS (HTTPS or WSS) in all of the use cases envisioned so far. If the UA cannot trust the device’s TLS server certificate, the UA shows a warning message that means the device cannot be trusted. To avoid it, the device shall have a way to prove its trustworthiness to the UA.

Getting a Web PKI certificate is one of the ways to prove the device trustworthiness but the Web PKI certificate only works for globally unique domains, which must be registered in public DNS servers. For this scenario, the requirement is that

However, one may choose to use a memorable simple private domain name (e.g., “myprinter.local”) or may not want to register the device name to the public DNS server because of privacy concerns. In such scenarios, it is better not to use the Web PKI certificate for the device, however, the device and/or the UA shall have one of the following features or methods:

3.2.2. Device Identification

In case that the user inputs the device URL to the address bar of the UA directly (§2.7 UC-07: Secure offline communication for home automation) or the UA shows the popup window to the user to get the user’s consent (§2.2 UC-02: Video streaming with cache storage in local network, §2.3 UC-03: Web-based UI for home appliances (input/output constrained devices)), the user may be able to recognize that the device URL displayed or input on the UA indicates the real device on the local network. In such cases, the device and/or the UA shall meet the following requirements:

3.2.3. Alerting User and User Consent

The frontend of the web service loaded on the UA should not be able to access the device without an explicit approval from the user especially during its first time access. This is essential in cases where the device is not capable of using a Web PKI certificate. In such cases, the UA will possibly use an alternative identifier (e.g., non-Web PKI certificate, PSK, RPK) but it must not be trusted without the user’s consent. Therefore, considering the UA shall meet the following requirement:

3.2.4. Certificate Management

When the device obtains a TLS server certificate for HTTPS/WSS communication, the CA, UA and the device shall meet the following requirements:

3.2.5. Device Discovery

As described in §2.2 UC-02: Video streaming with cache storage in local network and §2.3 UC-03: Web-based UI for home appliances (input/output constrained devices), when the web service does not know the device URL in advance, the device needs to be discovered. That means the discovery process must meet the following requirements:

3.3. Non-Functional Requirements

The non-functional requirements are listed below:

3.3.1. Security

It is essential to take care of the following security considerations:

3.3.2. Privacy

The user privacy shall be preserved against the web service especially when the user allows the frontend of the web service to access the device for private use. In such scenarios, the UA and the device shall meet the following requirements:

3.3.3. Availability

In scenarios (e.g., §2.7 UC-07: Secure offline communication for home automation) when the device and the UA gets temporarily disconnected from the internet, the UA and the device should be able to communicate with each other on the local network. Therefore, the device and the local network system shall meet the following requirements:

3.3.4. Scalability

If all IoT devices started using Web PKI certificates for HTTPS/WSS communication, the number of certificates required will be significantly larger than the total number of certificates exists today for public web servers. Therefore, following exemption may be required:

3.3.5. User Experience

While the user interaction is required in certain scenarios, it should not be a hindrance to providing a better user experience. Following requirements should be considered:

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

Informative References

[MIXED-CONTENT]
Mike West. Mixed Content. 2 August 2016. CR. URL: https://www.w3.org/TR/mixed-content/
[SECURE-CONTEXTS]
Mike West. Secure Contexts. 15 September 2016. CR. URL: https://www.w3.org/TR/secure-contexts/