Ethernet over HTTPS Protocol

Internet-Draft	EOH	December 2023
ARAM	Expires 29 June 2024	[Page]

Abstract

This document defines a protocol for encapsulating Ethernet frames over HTTPS, allowing secure communication between a client and internal web servers. The protocol includes authentication using strong API keys encrypted with the server's public key. The communication is secured using TLS for privacy and integrity.¶

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 29 June 2024.¶

Copyright Notice

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.¶

1. Introduction

Ethernet over HTTPS (EOH) extends traditional networking by allowing communication between a web client and internal resources over the HTTPS protocol. This document outlines the procedures for authentication, encapsulation of Ethernet frames, and communication between the client and internal web servers. TLS is employed to secure the communication channel and ensure privacy and integrity.¶

1.1. TLS Considerations

To ensure the security of the Ethernet-over-HTTPS communication, TLS must be used to encrypt and authenticate the data exchanged between the client and server. Implementations MUST follow best practices for TLS configuration, including the use of strong cipher suites, secure protocols, and proper certificate validation.¶

1.2. Flow and Scenarios

1.2.1. Client Authentication

If the client specifies an internal URL (e.g., internal.url), the browser recognizes that Ethernet over HTTPS should be used for the communication. The client browser, pre-configured with the IP address and port of the HTTP Server acting as the gateway to the LAN, automatically recognizes the internal URL (e.g., internal.url). It then initiates the Ethernet-over-HTTPS protocol and sends an authentication request.¶

The client initiates the connection by sending an authentication request to the server.¶

plaintext
POST /authenticate HTTP/1.1
Host: server.example.com
Content-Type: application/json

{
"api_key": "encrypted_api_key"
}

### Server Authentication and LAN Information The server decrypts the API key, authenticates the client, and responds with the MAC address or IP address of the target server (or both) based on the LAN layer architecture.¶

HTTP/1.1 200 OK
Content-Type: application/json

{
  "target_server_mac_address": "xx:xx:xx:xx:xx:xx",
  "target_server_ip_address": "192.168.1.2"
  "dhcp_ip_address": "192.168.1.10"
}

1.2.2. Internal Webpage Request

The client, now authenticated, sends an Ethernet frame encapsulated within an HTTPS request for an internal webpage¶

1.2.3. Server-Side Processing

The server decapsulates the Ethernet frame, extracts the original HTTP request, and routes it to the internal web server.¶

1.2.4. Response to the Client

The server encapsulates the response from the internal web server¶

POST /ethernet-over-https HTTP/1.1
Host: server.example.com
Content-Type: application/octet-stream
Content-Length: length_of_payload_in_bytes

{
  "http_response": "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n<html>Internal Webpage</html>"
}

2. FLow summary

  +----------------------+       +----------------------+
  |                      |       |                      |
  |      Web Client      |       |        EOH Server     |
  |                      |       |                      |
  +----------------------+       +----------------------+
           |                             |
           | 1. Browser Recognizes       |
           |    Internal URL             |
           | --------------------------> |
           |                             |
           | 2. Authentication Request   |
           | --------------------------> |
           |                             |
           |                             |
           | 3. Browser Initiates        |
           |    Ethernet over HTTPS      |
           |                             |
           |                             |
           | 4. Server Authenticates     |
           |    and Responds             |
           | <-------------------------- |
           |                             |
           | 5. Internal Webpage Request |
           |    as Encapsulated Frame    |
           | --------------------------> |
           |                             |
           | 6. Server Decapsulation     |
           |    and Routing              |
           | <-------------------------- |
           |                             |
           | 7. Response to Client       |
           |    as Encapsulated Frame    |
           | --------------------------> |
           |                             |

# Security Considerations The security of the Ethernet-over-HTTPS protocol relies on the implementation of TLS. It ensures the confidentiality, integrity, and authenticity of the communication between the client and server. Implementers should adhere to best practices for TLS configuration, including the use of strong cipher suites, secure protocols, and proper certificate validation.¶