Remote terminal over HTTP/3 connections

1.1.1. QUIC: datagrams, streams multiplexing and connection migration

Using QUIC, data can be sent through both reliable streams and unreliable datagrams. This makes the protocol able to support port forwarding for both UDP [UDP] and TCP-based protocols. Being based exclusively on TCP, SSHv2 does not offer UDP port forwarding and therefore provides no support to UDP-based protocols such as RTP or QUIC. This lack of UDP support in SSHv2 may become problematic as the use of QUIC-based applications (HTTP/3, MOQT [MOQT], DOQ [DOQ]) grows. Support for UDP port forwarding in this architecture also allows accessing real-time media content such as low-latency live video available on the server. The stream multiplexing capabilities of QUIC allow reducing the head-of-line blocking that SSHv2 encounters when multiplexing several SSH channels over the same TCP connection.¶

QUIC also supports connection migration (Section 9 of [QUIC]). Using connection migration, a mobile host roaming between networks can maintain established connections alive across different networks by migrating them on their newly acquired IP address. This avoids disrupting the remote terminal session upon network changes. Finally, QUIC also offers a significantly reduced connection establishment time compared to the SSHv2 session establishment.¶

1.1.2. Protecting transport-layer control fields

Since QUIC integrates authentication and encryption as part of its transport features, it makes remote terminals over HTTP/3 robust to transport-layer attacks that were possible with TCP, such as packet injections or reset attacks [RFC5961]. For instance, the recent Terrapin attack [TERRAPIN] manipulates the TCP sequence number to alter the SSH extension negotiation mechanism [RFC8308] and downgrade the client authentication algorithms. QUIC control information such as packet numbers and frame formats is authenticated and encrypted starting from the Handshake encryption level. Furthermore, QUIC prevents middlebox interference.¶

1.1.3. Leveraging the X.509 ecosystem

By using TLS for their secure channel establishment, HTTPS and QUIC leverage the X.509 certificates ecosystem with low implementation effort. TLS and QUIC libraries already implement support for generating, parsing and verifying X.509 certificates. Similarly to classical OpenSSH certificates, this avoids encouraging users to rely on the Trust On First Use pattern when connecting to their remote hosts. Relying on the X.509 certificates ecosystem additionally enables servers to use ACME [ACME] to automatically (with no additional user action) generate X.509 certificates for their domain names using well-known certificate authorities such as Let's Encrypt. These certificates are publicly valid and can be verified like classical TLS certificates. Client certificates can also be issued and used as an authentication method for the client.¶

1.1.4. HTTP authentication: compatibility with existing authentication systems

Using HTTP authentication schemes for user authentication allows implementing diverse authentication mechanisms such as the classical password-based and public key authentication, but also popular web authentication mechanisms such as OpenID Connect [OpenID.Core], SAML2 [OASIS.saml-core-2.0-os] or the recent Passkeys/WebAuthn standard [WebAuthn]. All these authentication schemes are already deployed for managing access to critical resources in different organizations. Sharing computing resources using SSHv2 through these mechanisms generally requires the deployment of a middleware managing the mapping between identities and SSH keys or certificates. HTTP authentication allows welcoming these authentication methods directly and and being interfaced naturally with existing infrastructures. As a proof-of-concept, OpenID Connect support has been added to our prototype [PROTOTYPE]. Other web authentication standards such as Passkeys/WebAuthn [WebAuthn] allow administrators to restrict remote access to specific client devices in addition to users.¶

1.1.5. URL multiplexing and undiscoverability

Relying on HTTP allows easily placing remote terminal endpoints as resources accessible through specific URLs. First, this makes it easier to integrate remote terminal endpoints on web servers that already perform user authentication and authorization. Second, it allows placing several remote terminal server instances on the same physical machine on the same port. These instances can run in different virtual machines, containers or simply different users with user's priviledges and be multiplexed on a URL-basis. Finally, remote terminal endpoints can be placed behind secret URLs, reducing the exposure of remote terminal hosts to scanning and brute force attacks. This goes in line with the will of having undiscoverable resources also tackled by other IETF working groups [HTTP-CONCEALED]. This property is not provided by SSHv2 since the SSHv2 server announces its SSH version string to any connected TCP client. If wanted, remote terminal hosts can be made indistinguishable from any HTTP server. This is however only complementary to and MUST NOT replace user authentication.¶

3.1.1. Password authentication using HTTP Basic Authentication

Password-based authentication is performed using the HTTP Basic authentication scheme [HTTP-BASIC]. The user-id part of the <credentials> in the Authorization header defined in [HTTP-BASIC] MUST be equal to the username variable in the request URI defined in Section 3.¶

  Client
     |                QUIC HANDSHAKE                 |
     |<--------------------------------------------->|
     |                                               |
     | HTTP/3, Stream x CONNECT /<path>?user=<user>  |
     |         :protocol="remote-terminal"           |
     |         Authorization="Basic <credentials>"   |
     |---------------------------------------------->|
     |                                               |
     |               HTTP/3, Stream x 200 OK         |
     |<----------------------------------------------|
     |                                               |
     |             Session established               |
     +-----------------------------------------------+
     |                                               |

3.1.2. Public key authentication using OAUTH2 and JWTs

Classical public key authentication can be performed using the OAUTH2 framework [OAUTH2]: the HTTP Bearer authentication scheme is used to carry an OAUTH access token encoded in the JWT [JWT] format [OAUTH2-JWT].¶

  Client
     |                QUIC HANDSHAKE                 |
     |<--------------------------------------------->|
     |                                               |
     | HTTP/3, Stream x CONNECT /<path>?user=<user>  |
     |         :protocol="remote-terminal"           |
     |         Authorization="Bearer <JWT token>"    |
     |---------------------------------------------->|
     |                                               |
     |               HTTP/3, Stream x 200 OK         |
     |<----------------------------------------------|
     |                                               |
     |             Session established               |
     +-----------------------------------------------+
     |                                               |

For classical client-server public key authentication with no third-party involved, only the following claims are required (see [JWT] for their definition):¶

• sub: set to remote-terminal-<user>¶

• iat: set to the date of issuance of the JWT¶

• exp: set to a short expiration value to limit the token replay window¶

The jti claim may also be used to prevent the token from being replayed.¶

3.1.3. Public key authentication using HTTP Concealed authentication

Public key authentication can also be performed using the HTTP Concealed Authentication scheme [HTTP-CONCEALED]. The <k> parameter designates the key ID of the public key used by the authentication process.¶

  Client
     |                QUIC HANDSHAKE                 |
     |<--------------------------------------------->|
     |                                               |
     | HTTP/3, Stream x CONNECT /<path>?user=<user>  |
     |    :protocol="remote-terminal"                |
     |    Concealed k=<k>, a=<a>,s=<s>,v=<v>,p=<p>   |
     |---------------------------------------------->|
     |                                               |
     |               HTTP/3, Stream x 200 OK         |
     |<----------------------------------------------|
     |                                               |
     |             Session established               |
     +-----------------------------------------------+
     |                                               |

4.1.1. Opening a channel

Channels can be opened on HTTP/3 client-initiated bidirectional streams. By default, HTTP/3 considers every client-initiated bidirectional stream as a request stream. Similarly to WebTransport, this protocol extends HTTP/3 using a specific signal value. A remote terminal client can open a stream with this signal value to indicate that it is not a request stream and that the remaining stream bytes will be used arbitrarily by the protocol to carry the content of a channel. For experimental purpose, the signal value is chosen at random and will change over time. The current signal value is 0x5e67730e. The content of an HTTP/3 stream carrying a remote terminal channel is illustrated below.¶

Channel {
    Signal Value (i) = 0x5e67730e,
    Session ID (i),
    Channel Type Length (i)
    Channel Type (..)
    Maximum Message Size (i)
    SSH messages (..)
}

The first value sent on the HTTP/3 stream is the Signal Value. The Channel Type is a UTF-8-encoded string whose length is defined by the Channel Type Length field.¶

[[Note: SSHv2 uses text-based channel types. Should we keep that or use something else instead ? If we change, we loose a 1-1 mapping with SSHv2.]]¶

The Maximum Message Size field defines the maximum size in bytes of SSH messages.¶

The remaining bytes of the stream are interpreted as a sequence of messages. Their format and length can vary depending on the message type (see Section 4.1.4).¶

4.1.2. Channel types

This document defines the following channel types, the four first being also defined in [SSH-CONNECT]:¶

• session¶

• x11¶

• direct-tcp¶

• reverse-tcp¶

• direct-udp¶

• reverse-udp¶

The direct-tcp and direct-udp channels offer TCP and UDP port forwarding from a local port on the client towards a remote address accessible from the remote host. The reverse-tcp and reverse-udp channels offer the forwarding of UDP packets and TCP connections arriving on a specific port on the remote host to the client.¶

4.1.3. Port forwarding

The HTTP bidirectional stream attached to the direct-tcp or reverse-tcp channel directly carries the TCP payload to forward.¶

For UDP forwarding, UDP packets are carried through HTTP Datagrams (Section 2 of [HTTP-DATAGRAM]) whose Quarter Stream IDs refer directly to the HTTP Stream ID of the corresponding direct-udp or reverse-udp channel.¶

Forwarding of other layers (e.g. IP) is left for future versions of the document.¶

4.1.4. Messages

Messages are exchanged over channels similarly to SSHv2. The same message format as the one defined in [SSH-CONNECT] applies, with channel numbers removed from the messages headers as channel run over dedicated HTTP streams. Hereunder is an example showing the wire format of the exit-status message. Its SSHv2 variant is described in Section 6.10 of [SSH-CONNECT].¶

ExitStatusMessage {
    Message Type (string) = "exit-status",
    Want Reply (bool) = false,
    Exit Status (i)
}