]> Secure shell over HTTP/3 connections UCLouvain
francois.michel@uclouvain.be
UCLouvain and WELRI
olivier.bonaventure@uclouvain.be
sec Security Dispatch ssh ssh3 http h3 quic tls The secure shell (SSH) traditionally offers its secure services over an insecure network using the TCP transport protocol. This document defines mechanisms to run the SSH protocol over HTTP/3 using Extended CONNECT. Running SSH over HTTP/3 enables additional benefits such as the scalability offered by HTTP multiplexing, relying on TLS for secure channel establishment leveraging X.509 certificates, HTTP Authentication schemes for client and server authentication, UDP port forwarding and stronger resilience against packet injection attacks and middlebox interference. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .
Introduction The SSH protocol provides a secure way to access computers remotely over an untrusted network. SSH is currently the most popular way to access Unix hosts and network equipments remotely. Built atop the unencrypted TCP protocol , SSH proposes its own mechanisms to establish a secure channel and perform user authentication . Once the secure session is established and the user is authenticated and authorized, SSH uses the Connection protocol to run and manage remote processes and functionalities executed on the remote host . Among others, SSH provides different services such as remote program execution, shell access and TCP port forwarding. provides a graphical representation of the SSHv2 protocol stack.
The SSHv2 architecture protocol stack.
This document defines mechanisms to run the SSH Connection protocol over HTTP/3 and uses the name "SSH3" to refer to this solution. The secure channel establishment uses TLS included in QUIC while user authentication is performed using existing HTTP authentication schemes, focusing the design of SSH on the Connection protocol itself. provides a graphical representation of the architecture proposed in this document. One benefit of the approach is that the HTTP3 and QUIC layers can evolve independently of SSH. For instance, new encryption and MAC algorithms can be added to TLS and used in SSH3 without impacting the specification or adding new code points in SSH3 for these new algorithms.
The proposed SSH3 architecture.
The mechanisms used for establishing an SSH3 conversation are similar to the WebTransport session establishment . WebTransport is also a good transport layer candidate for SSH3. The current SSH3 prototype is built directly over HTTP/3 since there is no public WebTransport implementation meeting all our requirements as of now. The semantics of HTTP/2 being comparable to HTTP/3, the mechanisms defined in this document could be implemented using HTTP/2 if a fallback to TCP is required. There is an ongoing effort to be able to run HTTP/3 over QUIC on TCP Streams . This document is a first introductory document. We limit its current scope to HTTP/3 using the classical QUIC.
How SSH benefits from HTTP/3 Using HTTP/3 and QUIC as a substrate for SSH brings several different benefits that are highlighted in this section.
QUIC: datagrams support, streams multiplexing and connection migration Using QUIC, SSH3 can send data through both reliable streams and unreliable datagrams. This makes SSH3 able to support port forwarding for both 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 , DOQ ) grows. Support for UDP port forwarding with SSH3 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 (). 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 SSH conversation upon network changes. Finally, QUIC also offers a significantly reduced connection establishment time compared to the SSHv2 session establishment.
Protecting transport-layer control fields Since QUIC integrates authentication and encryption as part of its transport features, it makes SSH3 robust to transport-layer attacks that were possible with TCP, such as packet injections or reset attacks . For instance, the recent Terrapin attack manipulates the TCP sequence number to alter the SSH extension negotiation mechanism and downgrade the client authentication algorithms. QUIC control information such as packet numbers and frame formats are all authenticated and encrypted starting from the Handshake encryption level. Furthermore, QUIC prevents middlebox interference.
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 SSH 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 SSH3 servers to use 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 HTTPS certificates. Client certificates can also be issued and used as an authentication method for the client.
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 , SAML2 or the recent Passkeys/WebAuthn standard . 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. Adding HTTP authentication to SSH allows welcoming these authentication methods directly and interfaces SSH3 more naturally with existing architectures. As a proof-of-concept, OpenID Connect support has been added to our SSH3 prototype . Other web authentication standards such as Passkeys/WebAuthn allow administrators to restrict remote access to specific client devices in addition to users.
URL multiplexing and undiscoverability Relying on HTTP allows easily placing SSH endpoints as resources accessible through specific URLs. First, this makes it easier to integrate SSH endpoints on web servers that already perform user authentication and authorization. Second, it allows placing several SSH 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, SSH3 endpoints can be placed behind secret URLs, reducing the exposure of SSH3 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 . This property is not provided by SSHv2 since the SSHv2 server announces its SSH version string to any connected TCP client. If wanted, SSH3 hosts can be made indistinguishable from any HTTP server. This is however only complementary to and MUST NOT replace user authentication.
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.
Establishing an SSH3 conversation We choose the term "conversation" to avoid ambiguities with the existing concepts of SSH shell session and QUIC connection. An SSH3 conversation can be started using the HTTP/3 Extended CONNECT method . The :protocol pseudo-header MUST be set to ssh3 and the :scheme pseudo-header MUST be set to https. If an SSH3 client or server supports the UDP forwarding feature, it MUST indicate support for HTTP/3 datagrams by sending a SETTINGS_H3_DATAGRAM value set to 1 in their SETTINGS frame (). An SSH3 server listens for CONNECT requests with the ssh3 protocol on URI templates having the username variable. Example URIs can be found below. [[Note: In the current prototype , percent-encoding is used for characters outside the allowed set of . An alternative can be to perform base64url encoding of the username instead.]] illustrates a successful SSH3 conversation establishment.
SSH3 successful conversation establishment. | | | | HTTP/3, Stream x CONNECT /?user= | | :protocol="ssh3" | | Authorization= | |---------------------------------------------->| | | | HTTP/3, Stream x 200 OK | |<----------------------------------------------| | | | Conversation established | --+-----------------------------------------------+-- | | | (endpoints now run the SSH Connection) | | (protocol over QUIC streams ) | | | ]]>
Authentication material is placed inside the Authorization header of the Extended CONNECT request. The format and value of <auth_material> depends on the HTTP authentication scheme used ( explores several examples of authentication mechanisms). If an SSH3 endpoint is available to the HTTP/3 server and if the user is successfully authenticated and authorized, the server responds with a 2xx HTTP status code and the conversation is established. The stream ID used for the Extended CONNECT request is then remembered by each endpoint as the SSH conversation ID, uniquely identifying this SSH conversation.
Authenticating the client Authorization of the CONNECT request is done using HTTP Authorization as defined in , with no restriction on the authentication scheme used. If no Authorization header is present in the request or if the authentication scheme is not supported by the server, the server SHOULD respond with a 401 (Unauthorized) response message. Once the user authentication is successful, the SSH3 server can process the request and start the conversation. This section only provides example user authentication mechanisms. Other mechanisms may be proposed in the future in separate documents. The two first examples are implemented by our current prototype . The third example leverages the Signature authentication scheme and will be preferred for public key authentication in future versions of our prototype.
Password authentication using HTTP Basic Authentication Password-based authentication is performed using the HTTP Basic authentication scheme . The user-id part of the <credentials> in the Authorization header defined in MUST be equal to the username variable in the request URI defined in . | | | | HTTP/3, Stream x CONNECT /?user= | | :protocol="ssh3" | | Authorization="Basic " | |---------------------------------------------->| | | | HTTP/3, Stream x 200 OK | |<----------------------------------------------| | | | Conversation established | +-----------------------------------------------+ | | ]]>
Public key authentication using OAUTH2 and JWTs Classical public key authentication can be performed using the OAUTH2 framework : the HTTP Bearer authentication scheme is used to carry an OAUTH access token encoded in the JWT format . | | | | HTTP/3, Stream x CONNECT /?user= | | :protocol="ssh3" | | Authorization="Bearer " | |---------------------------------------------->| | | | HTTP/3, Stream x 200 OK | |<----------------------------------------------| | | | Conversation established | +-----------------------------------------------+ | | ]]> For classical client-server public key authentication with no third-party involved, only the following claims are required (see for their definition):
  • sub: set to ssh3-<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.
Public key authentication using HTTP Signature authentication Public key authentication can also be performed using the HTTP Signature Authentication scheme . The <k> parameter designates the key ID of the public key used by the authentication process. Classical SSH implementations usually do not assign IDs to public keys. The value <k> can therefore be set to the cryptographic hash of the public key instead. | | | | HTTP/3, Stream x CONNECT /?user= | | :protocol="ssh3" | | Signature k=, a=,s=,v=,p=

| |---------------------------------------------->| | | | HTTP/3, Stream x 200 OK | |<----------------------------------------------| | | | Conversation established | +-----------------------------------------------+ | | ]]>

Mapping the SSH Connection protocol This document reuses the SSH Connection protocol defined in . SSH Channels are run over their dedicated HTTP streams and carry SSH messages. The boolean and string data types defined in are reused. The byte, uint32 and uint64 data types are replaced by variable-length integers as defined in .
Channels Similarly to , SSH3 defines bidirectional channels over which the endpoints exchange SSH messages. Each channel runs over a bidirectional HTTP/3 stream and is attached to a single SSH conversation. In this document, channels are therefore not assigned a channel number conversely to SSHv2.
Opening a channel SSH 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, SSH3 extends HTTP/3 using a specific signal value. An SSH3 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 SSH3 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 0xaf3627e6. The content of an HTTP/3 stream carrying an SSH3 channel is illustrated below. 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 SSH messages. Their format and length can vary depending on the message type (see ).
Channel types This document defines the following channel types, the four first being also defined in :
  • 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.
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 () 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.
Messages Messages are exchanged over channels similarly to SSHv2. The same message format as the one defined in 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 SSH message for SSH3. Its SSHv2 variant is described in .
SSH3 and MASQUE SSH3 shares common objectives with the MASQUE proxy and while it is currently out of scope of this introductory document, interactions between the two protocols may exist in the future. For instance, a MASQUE endpoint can be integrated with SSH3 to provide diverse forwarding services. Another possible outcome is the integration of SSH3 in the MASQUE family of proxies in the form of a "CONNECT-SHELL" endpoint.
Version Negotiation For SSH3 implementations to be able to follow the versions of this draft while being interoperable with a large amount of peers, we define the "ssh-version" header to list the supported draft versions. The value of this field sent by the client is a comma-separated list of strings representing the filenames of the supported drafts without the "draft-" prefix. For instance, SSH3 clients implementing this draft in versions 00 and 01 send the "ssh-version: michel-ssh3-00,michel-ssh3-01" HTTP header in the CONNECT request. Upon receiving this header, the server chooses a version from the ones supported by the client. It then sets this single version as the value of the "ssh-version" header.
Compatibility with SSHv2 and TCP-only networks While the protocol described in this document is not directly compatible with SSHv2, mechanisms can be defined in the future to announce the availability of SSH3 and upgrade to SSH3 from SSHv2 sessions. SSH3 can also be made available on networks supporting only TCP using either HTTP/2 or HTTP/3 with QUIC on Streams as a substrate for SSH3.
Security Considerations Running an SSH3 endpoint with weak or no authentication methods exposes the host to non-negligible risks allowing attackers to gain full control of the server. SSH3 servers should not be run without authentication and user authentication material should be verified thoroughly. Public key authentication should be preferred to passwords. It is recommended to deploy public TLS certificates on SSH3 servers similarly to classical HTTPS servers. Using valid public TLS certificates on the server allows their automatic verification on the client with no explicit user action required. Connecting an SSH3 client to a server with a certificate that cannot be validated using the client's trusted Certificate Authorities exposes the user to the same risk incurred by SSHv2 endpoints relying on Host keys: the user needs to manually validate the certificate before connecting. Ignoring this verification may allow an attacker to impersonate the server and access the keystrokes typed by the user during the conversation.
IANA Considerations
HTTP Upgrade Token This document will request IANA to register "ssh3" in the "HTTP Upgrade Tokens" registry maintained at https://www.iana.org/assignments/http-upgrade-tokens. [[Note: This may be removed if we decide to run SSH3 atop WebTransport instead of HTTP/3 only.]]
References Normative References HTTP/2 This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. HTTP/3 The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. The Secure Shell (SSH) Protocol Architecture The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK] The Secure Shell (SSH) Authentication Protocol The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] The Secure Shell (SSH) Transport Layer Protocol The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK] The Secure Shell (SSH) Connection Protocol Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. [STANDARDS-TRACK] HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The 'Basic' HTTP Authentication Scheme This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. JSON Web Token (JWT) JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. QUIC: A UDP-Based Multiplexed and Secure Transport This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Using TLS to Secure QUIC This document describes how Transport Layer Security (TLS) is used to secure QUIC. QUIC Loss Detection and Congestion Control This document describes loss detection and congestion control mechanisms for QUIC. JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. Bootstrapping WebSockets with HTTP/2 This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. HTTP Datagrams and the Capsule Protocol This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. WebTransport over HTTP/3 Facebook Apple Inc. Google WebTransport [OVERVIEW] is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams and datagrams, all multiplexed within the same HTTP/3 connection. The Signature HTTP Authentication Scheme Google LLC Guardian Project Cloudflare Inc. Existing HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes, however that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed, and there is no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document proposes a new non-probeable cryptographic authentication scheme. Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] DNS over Dedicated QUIC Connections This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. Transmission Control Protocol (TCP) This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. User Datagram Protocol Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 The OAuth 2.0 Authorization Framework The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] Media over QUIC Transport Discord Meta Cisco Google Google This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. The MASQUE Proxy Google LLC MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees. OpenSSH release 5.4 QUIC on Streams Fastly Cloudflare This document specifies a polyfill of QUIC version 1 that runs on top of bi-directional streams such as TLS. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/kazuho/draft-kazuho-quic-quic-on-streams. PuTTY Certificates Tectia Certificates Improving TCP's Robustness to Blind In-Window Attacks TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [STANDARDS-TRACK] Automatic Certificate Management Environment (ACME) Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. Terrapin Attack: Breaking SSH Channel Integrity By Sequence Number Manipulation Extension Negotiation in the Secure Shell (SSH) Protocol This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. OpenID Connect Core 1.0 n.d. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 n.d. Web Authentication: An API for accessing Public Key Credentials Level 3 n.d. SSH3: faster and rich secure shell using HTTP/3 n.d.
Acknowledgments We warmly thank Maxime Piraux, Lucas Pardue and David Schinazi for their precious comments on the document before the submission. We also thank Ryan Hurst for all the motivating discussions around the protocol.