RFC 7869

The "vnc" URI Scheme

📅 published May 2016, from ietf

RFC 7869: The "vnc" URI Scheme 🎀

Okay bestie, this one is an Informational doc (not a Standards Track thing) from May 2016, published as an Independent Submission 💅. It's by D. Warden from Dell Products LP and I. Iordanov from Undatech, and it's logged under ISSN 2070-1721. It doesn't list anything it obsoletes or updates, so it's a clean slate 🫶.

Abstract ✨

Virtual Network Computing (VNC) software gives you remote desktop functionality 🖥️🌸. This doc defines a Uniform Resource Identifier (URI) scheme that lets other apps launch VNC clients 🚀. It also includes parameters that help you connect to remote hosts securely 🔐.

Status of This Memo 📜

Not a Standards Track spec, just published for info 📚.

It's a contribution to the RFC Series, sitting independently of any other RFC stream 🦋. The RFC Editor picked to publish it at their discretion and makes no statement about its value for implementation or deployment 🤷‍♀️. Docs the RFC Editor approves aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741 ✨.

Info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7869 💜.

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date 📑. Read them carefully, because they spell out your rights and restrictions for this doc 🙈.

Table of Contents 🧚

   1. Introduction ....................................................3
      1.1. Requirements Language ......................................3
   2. The "vnc" URI Scheme ............................................3
      2.1. URI Scheme Syntax ..........................................3
           2.1.1. URI Parameters ......................................4
           2.1.2. Data Types ..........................................9
      2.2. Processing URIs ...........................................11
           2.2.1. Error Handling .....................................12
           2.2.2. Connection Profile Matching ........................12
      2.3. Connection Channel Types ..................................12
           2.3.1. The "Integrated SSH" Channel Type ..................12
           2.3.2. The "Secure Tunnel" Channel Type ...................14
   3. Security Considerations ........................................15
      3.1. Application Trust .........................................16
      3.2. URI Handling ..............................................16
      3.3. Host Identification .......................................17
      3.4. Connection Database Integrity .............................18
   4. IANA Considerations ............................................18
      4.1. "vnc" Scheme ..............................................18
      4.2. Remote Framebuffer Security Types .........................18
      4.3. VNC URI Group .............................................19
      4.4. VNC URI Connection Channel Types ..........................19
      4.5. VNC URI ID Hash Algorithms ................................19
      4.6. VNC URI Parameters ........................................21
   5. References .....................................................22
      5.1. Normative References ......................................22
      5.2. Informative References ....................................23
   Appendix A. "vnc" URI Template ....................................24
   Acknowledgments ...................................................25
   Authors' Addresses ................................................25

1. Introduction 🌈

VNC clients are how you get remote desktop connectivity going, built on the Remote Framebuffer (RFB) Protocol [RFC6143] 🖥️💕. People want to plug this into other software all the time, but there's no standard way to specify VNC client parameters, so that integration has been held back 😭.

The "vnc" Uniform Resource Identifier (URI) scheme in this doc is the fix 🦋. It makes launching VNC clients from apps in browser, desktop, and mobile environments way easier 🚀. With it, users and app vendors can add remote desktop features without being locked to one particular client 👑.

Remote desktop clients usually keep connection profiles in a local connection database 🗂️. If you link the connections in a URI to the ones stored in that database, client-specific options can get applied automatically to a connection launched from some other app 🪄. That works even when the other app has no idea those options exist ✨.

VNC servers are often secured with TLS/SSL tunneling [RFC5246] and SSH [RFC4251] tunneling 🔒. Those live outside the RFB protocol itself 💅. This doc defines how these client-integrated security options behave, so you can use them with "vnc" URIs 🫶.

1.1. Requirements Language 📏

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Here's the catch: these words only carry that meaning when they're in ALL CAPS 🙌. Lowercase versions aren't supposed to be read with the RFC 2119 significance 🙈.

2. The "vnc" URI Scheme 🎀

2.1. URI Scheme Syntax 🧩

The normative syntax of the "vnc" URI is the <vnc-uri> rule in the spec below 📐. It's written in Augmented Backus-Naur Form (ABNF) as described in [RFC5234] 💜. The "vnc" URI follows the generic URI syntax from [RFC3986] ✨. The <userinfo>, <host>, <port>, <unreserved>, and <pct-encoded> rules all come from [RFC3986] too 🌸.

   vnc-uri = "vnc://" [ userinfo "@" ] [ host [ ":" port ] ]
             [ "?" [ vnc-params ] ]

   vnc-params = param "=" value *("&" param "=" value) ["&"]

   param = 1*( param-char )

   value = *( param-char )

   param-char = unreserved / pct-encoded / unreserved-symbols

   unreserved-symbols = ":" / "/" / "@" / "!" / "$" / "'"
                        / "(" / ")" / "*" / "," / ";"

Okay so the ?, =, and & characters are what separate VNC parameters, and when they show up as data octets they must be percent-encoded as specified in [RFC3986] 🚫. Inside the <vnc-params> part, the <unreserved-symbols> don't have any special meaning, so they need not be percent-encoded when they show up as data octets 💅.

A "vnc" URI has the general form:

   vnc://host:port?param1=value1&param2=value2...

The host info and each parameter value give the info used to set up or run the remote desktop session, as specified in Section 2.1.1 🖥️✨.

Here's an example:

   vnc://10.0.0.1:5901?VncPassword=secret&SecurityType=2

This one points to a VNC connection on host 10.0.0.1, port 5901, with VNC password secret, using the VNC Authentication security type 🔐💖.

2.1.1. URI Parameters ✨

okay bestie, let's talk about the parameters 💖 they're all technically optional, but ngl a client literally can't connect without enough info to actually find a server 😭

Info on what each data type can look like is in Section 2.1.2. If a parameter doesn't have a default value listed, that means this URI scheme doesn't imply one. VNC clients can still apply their own implementation-dependent defaults, as long as those stay consistent with this document 🧚

The <userinfo> value is deprecated 🙈 and only gets processed in an implementation-specific way. The <userinfo> component MUST NOT be generated in an environment where a client supporting an updated URI format is expected to be available. When a client gets a URI from an untrusted source, it SHOULD alert the user. This is so nobody gets tricked, since a URI can be built to hide who the remote host really is, unless the URI can be validated or backwards-compatibility makes an alert impractical 🚨

The <host> and <port> values in the "vnc" URI tell you the address of the VNC server on the remote host:

   +------------+------------+-----------------------------+----------+
   | Name       | Type       | Description                 | Default  |
   +------------+------------+-----------------------------+----------+
   | host       | string     | VNC server hostname or IP   | none     |
   +------------+------------+-----------------------------+----------+
   | port       | ushort     | VNC server port             | 5900     |
   +------------+------------+-----------------------------+----------+

The "vnc" URI parameter values are the main character of remote desktop connection and session properties 💅 They cover client operation, usability, and security, as you can see in the table below:

   +---------------+---------+-----------------------------+----------+
   | Name          | Type    | Description                 | Default  |
   +---------------+---------+-----------------------------+----------+
   |ConnectionName | string  | Name of connection profile  | none     |
   +---------------+---------+-----------------------------+----------+
   |VncUsername    | string  | VNC server username         | none     |
   +---------------+---------+-----------------------------+----------+
   |VncPassword    | string  | VNC server password         | none     |
   +---------------+---------+-----------------------------+----------+
   |SecurityType   | enum    | RFB security type used      | none     |
   |               | <rfbsec>|                             |          |
   +---------------+---------+-----------------------------+----------+
   |ChannelType    | enum    | Connection channel type     | none     |
   |               | <chan>  |                             |          |
   +---------------+---------+-----------------------------+----------+
   |SshHost        | string  | SSH server hostname or IP   | <host>   |
   +---------------+---------+-----------------------------+----------+
   |SshPort        | ushort  | SSH server port             | 22       |
   +---------------+---------+-----------------------------+----------+
   |SshUsername    | string  | SSH username                | none     |
   +---------------+---------+-----------------------------+----------+
   |SshPassword    | string  | SSH password                | none     |
   +---------------+---------+-----------------------------+----------+
   |IdHashAlgorithm| enum    | Hash algorithm used with    | none     |
   |               | <idhash>| "IdHash" parameter          |          |
   +---------------+---------+-----------------------------+----------+
   |IdHash         | string  | Expected hash of remote     | none     |
   |               | <hex>   | public key or certificate   |          |
   +---------------+---------+-----------------------------+----------+
   |ColorLevel     | enum    | Client color depth/mode     | none     |
   |               | <clevel>|                             |          |
   +---------------+---------+-----------------------------+----------+
   |ViewOnly       | boolean | Client is view only         | false    |
   +---------------+---------+-----------------------------+----------+
   |SaveConnection | boolean | Store connection info       | none     |
   +---------------+---------+-----------------------------+----------+

ConnectionName, SaveConnection 🍓

"ConnectionName" is how you identify a connection profile in both the launching application and the VNC client. Profiles get applied as described in Section 2.2.2. If it's omitted, the client MAY generate a name based on the host, port, and/or other parameters. The VNC client MAY normalize the name as required.

If it's true, "SaveConnection" means a connection profile should be created or updated and stored in the client connection database. If it's false, no profile should be updated or persisted. 💾

VncUsername, VncPassword, SecurityType 🔐

The "SecurityType" parameter tells you which RFB security type applies to the connection. RFB security types are recorded in the IANA "Remote Framebuffer Security Types" registry created by [RFC6143]. The VNC client uses this info to figure out which parameters are required and then sets up the connection.

VNC clients can sometimes negotiate a security type with a server automatically. Specifying the security type takes control of that security negotiation. It also lets a client prompt for the security parameters it needs before connecting, which matters because parameters can take forever to type on mobile clients and could otherwise cause timeouts and/or security lockouts 😩 If the server doesn't support the specified type, an error SHOULD be indicated as described in Section 2.2.1.

"VncUsername" and "VncPassword" are used, when applicable, to authenticate to the VNC server with the specified "SecurityType". Passwords often contain arbitrary characters, so they'll often need percent encoding 🙃

ChannelType 🛤️

"ChannelType" specifies the transport stream used to carry connection data. This lets a client start a connection over a secure transport protocol such as SSH before it connects to the VNC server socket. How this value works with the "Integrated SSH" and "Secure Tunnel" channel types is covered in Section 2.3.

SshHost, SshPort, SshUsername, SshPassword 🐚

The SSH parameters are meant for the "Integrated SSH" channel type described in Section 2.3.1. They can also be used with any future SSH-based channel types. Passwords often contain arbitrary characters, so they'll often need percent encoding.

IdHashAlgorithm, IdHash 🪪

The "IdHashAlgorithm" and "IdHash" values verify the expected identity of the remote system, based on its public key or certificate. How they work with the "Integrated SSH" and "Secure Tunnel" channel types is covered in Section 2.3.

ColorLevel 🎨

The "ColorLevel" parameter specifies the color model used for data transfer and display, as described in Section 2.1.2. If the requested color model is unsupported, the behavior is implementation dependent.

ViewOnly 👀

If "ViewOnly" is true, the VNC client SHOULD operate in a display-only mode and refrain from sending input data, including KeyEvent, PointerEvent, and ClientCutText messages specified in Section 7.5 of [RFC6143], unless the client doesn't support this mode.

Parameter names SHOULD be provided in the case specified in this document. However, for compatibility, clients SHOULD accept parameters in a case-insensitive manner. Values SHALL be interpreted in a case-sensitive manner, unless otherwise noted 🌸

Additional parameters that are likely to be useful with multiple VNC clients can be added to the "VNC URI Parameters" registry, as specified in Section 4.6 of this document. Individual clients MAY support parameters specific to that client. VNC clients that support application-specific parameters SHOULD include a distinguishing prefix in the parameter name, such as the name of the application package specified in source code, except when compatibility constraints get in the way. For example:

   vnc://?com.dell.vncclient.ScreenMode=2&

It can also be expected that clients will keep backward compatibility with legacy URI formats and parameters 🦋

Legacy software applications respond to "vnc" URIs in different ways and may fail to behave as expected. It's advisable to test "vnc" URIs with specific applications, or to check the application-specific documentation 🧐

2.1.2. Data Types 💖

okay bestie, let's talk about the data types 🎀 "vnc" URIs can be percent-encoded as described in [RFC3986], and you MUST decode them first 🔥. Once they're decoded, these type rules and meanings kick in ✨

  • string

"string" values are UTF-encoded strings, following [RFC3629] 🌸

The "string<hex>" subtype is the one used in "IdHash". It's a bunch of colon-delimited ":" octets shown in hex, like this 🦋

5D:D2:39:57

Comparing "string<hex>" values SHALL be case insensitive 🙈 BUT uppercase is the preferred look for readability, so that's the vibe we go with 💅

  • enum

"enum" types are a set of specific enumerated subtypes, and they show up as their decimal value 🧚

"enum<rfbsec>" values are RFB security types from the IANA "Remote Framebuffer Security Types" registry that [RFC6143] created 🔐

"enum<chan>" values are connection channel types from the "VNC URI Connection Channel Types" registry, which Section 4.4 of this document creates 👑 The starting values are:

Value     Description
--------  --------------
1         Standard TCP
23        Secure Tunnel
24        Integrated SSH

"Standard TCP" is just a generic TCP connection ✨ The "Secure Tunnel" and "Integrated SSH" [RFC4252] channel types get the full tea in Section 2.3 💜

"enum<idhash>" values are secure hash algorithms from the "VNC URI Hash Algorithms" registry, which Section 4.5 of this document creates 🌈 The initial values include:

Value     Description
--------  ------------
1         MD5
2         SHA1
4         SHA256

MD5 is described in [RFC1321] 🍓 SHA-1 and SHA-256 are described in [SHS] 🫶

"enum<clevel>" values are color levels 🎨 In the table below, the columns mean what Section 7.4 of [RFC6143] says they mean:

BPP = bits-per-pixel
TC = true-color-flag
RM = red-max
GM = green-max
BM = blue-max
RS = red-shift
GS = green-shift
BS = blue-shift

And here are the values, slay 💅

Value  Description      BPP Depth TC RM   GM   BM   RS GS BS
-----  ---------------  --- ----- -- ---- ---- ---- -- -- --
1      Black and White  8   3     t  1    1    1    2  1  0
2      Grayscale        8   6     t  3    3    3    4  2  0
3      8 Colors         8   3     t  1    1    1    2  1  0
4      64 Colors        8   6     t  3    3    3    4  2  0
5      256 Colors       8   8     t  7    7    3    0  3  6
6      16-bit Color     16  16    t  31   63   31   11 5  0
7      24-bit Color     32  24    t  255  255  255  16 8  0
8      30-bit Color     32  30    t  1023 1023 1023 0  10 20

A value of "t" means the true-color-flag should be set ✨ The big-endian-flag (see Section 7.4 of [RFC6143]) should be set as required for the system 🦋

  • ushort

"ushort" values are unsigned 16-bit integers written in decimal digits, with a value from 0-65535 inclusive 🔢

  • boolean

"boolean" values are conditions that are either true or false, written as "true" or "false" respectively 💫 For maximum compatibility, clients SHOULD accept the value 1 as true and 0 as false 🌸 Clients SHOULD parse "boolean" values case-insensitively 🙌

Here's an example "vnc" URI that uses several of these types 👀

vnc://localhost:5900?ConnectionName=Server&SecurityType=2&
   IdHash=0D:3A:72:08:57:EA:4D:30&SaveConnection=false&

Quick note: the example above should be considered one contiguous string with no line breaks or whitespace. It's only split up across lines here so it's easier to read 📖

2.2. Processing URIs 🦋

Conceptually, a "vnc" URI only supports a "VIEW" operation 👀 That just means the user wants to view the remote desktop that's reachable through the URI reference 💜

Generally speaking, when a VNC client gets a "vnc" URI, it starts a remote desktop connection over the RFB protocol using the host info and parameter values it was given 🖥️ Starting the connection through a connection channel mechanism, like the ones in Section 2.3, might need some processing before the RFB connection gets set up 🔧 A client MAY try to automatically discover or negotiate an appropriate connection channel, security, or other parameter values 🧠

How security types get negotiated is specified in [RFC6143] 🔐 Supported connection channels can be discovered by testing channel types to see which one successfully establishes a channel ✨ To play nicely with other apps, the VNC client SHOULD start the connection with minimal or no user intervention, whenever there's enough information and adequate security is preserved 🫶

Host info and parameter values can also come through connection profiles 📁 When a parameter value isn't available from either the URI or a connection profile described in Section 2.2.2, the default value specified in Section 2.1.1 SHOULD be applied 💅 If the available parameters aren't enough to set up a connection, the VNC client SHOULD show a session initiation data-entry screen 🌈

2.2.1. Error Handling 🚨

In a typical interactive environment, if an error stops a session from being established, the VNC client shows an error message to the user 💬 Once that message is acknowledged, the console application can show a session initiation data-entry screen filled with the available session parameters, or it can terminate 🙃 If an error happens after a session has been successfully established and ends the connection, the VNC client shows a termination notification to the user 😭 Once that notification is acknowledged, the client can show a reconnection prompt or terminate 🔄

When an error happens in a dedicated environment, like a kiosk system, the system can send an alert to the remote operator, record a log entry, and run appropriate fallback behavior 🏧 Examples of that fallback are automatically trying to reestablish a session or showing a generic message that asks for servicing 🛠️

2.2.2. Connection Profile Matching 🗂️

VNC clients MAY store remote desktop session settings in connection profiles 💾 If the client can uniquely identify and link a connection request to a connection profile, based on the "ConnectionName" parameter value, the remote host IP address, or the hostname / fully qualified domain name, the VNC client SHOULD apply the profile values for any settings that don't have values supplied in the "vnc" URI 🎯 When profile data isn't available, the VNC client MAY apply global application defaults for settings that aren't supplied in the URI and that the scheme doesn't give a default value for 🌟 The VNC client MUST NOT override supplied parameters with profile values or global defaults 🚫 No cap, this one's important 😤

When the "SaveConnection" parameter value is true, a connection profile SHOULD be created or updated inside the VNC client with the values from the "vnc" URI 💖 Profile updates and storage should be consistent with the recommendations in Section 3.4 📚

2.3. Connection Channel Types 🧚

2.3.1. The "Integrated SSH" Channel Type 🔐

The "Integrated SSH" channel type sets up an SSH connection to a host, authenticates with SSH password authentication, builds a secure tunnel to the VNC host/port, and then connects to the VNC server using a supported "SecurityType" 🦋 The secure tunnel gives you encryption and data integrity, and verifying the public key is what proves the server is legit 🫶 The SSH architecture is specified in [RFC4251] 📖 Here are the steps, bestie:

  1. The VNC client starts a transport-level connection to the "SshHost" on the "SshPort" from the parameter values, with a key exchange as described in [RFC4253] 🔑
  2. When the VNC client gets the server key (or certificate), the hash of that key (or certificate) is computed with the algorithm that matches the "IdHashAlgorithm" parameter value, and then compared with the expected "IdHash" value, if there is one 🧮 If the certificate hash can't be verified, the client alerts the user or operator ⚠️ In a typical interactive environment, the alert includes the remote system's identifying info, the hash value, and lets the user end the connection 🛑 The alert could also let the user accept the key and keep setting up the connection 🤞 In a dedicated environment, like a kiosk system, the system can send an alert to the remote operator, record a log entry, and run appropriate fallback behavior, such as showing a generic message that asks for servicing 🏧
  3. The SSH client authenticates the user with the "SshUsername" and "SshPassword" parameter values, following the "password" authentication mechanism in [RFC4252] 🪪
  4. The SSH client opens a TCP/IP channel, as specified in [RFC4254], from the local system to the system named by the <host> and <port> info values 🛣️
  5. The VNC client sets up an RFB connection to the VNC server over that channel and authenticates using the "SecurityType", as described in [RFC6143] or some other reference 🎉

The VNC client MAY set up the connection described in this section using an external SSH client, by launching that client and then connecting to a secure tunnel between a local port and the VNC server 🚀

If the VNC client gets extra parameters that are outside the scope of this document, it MAY do a variation of these steps that fits the underlying protocols, for example by using "publickey" SSH client authentication [RFC4252] or by providing another form of authentication to the VNC server 🗝️ How SSH parameters get negotiated, like cipher suite configuration, is outside the scope of this document 🙅‍♀️

Lots of SSH clients show key hashes using MD5, and you can expect launching apps to specify that the hash gets displayed in the way its users are used to 👀

For compatibility, when the "SecurityType" parameter value is "Integrated SSH" (24), a VNC client MUST treat that value as a request to use "Integrated SSH" as the "ChannelType" ⚠️ HOWEVER, this value SHOULD NOT be supplied for the "SecurityType" parameter unless it's required for backward compatibility, because the channel gets established before connecting to the server and doesn't line up with how other security types are negotiated 💀

2.3.2. The "Secure Tunnel" Channel Type ✨

okay so the "Secure Tunnel" channel type is giving full encryption energy 🔒🫶. The VNC client sets up a TLS connection to a remote server using certificate authentication, and then the connection to the VNC server runs through that tunnel using a supported "SecurityType". The tunnel gives you encryption and data integrity, and checking the certificate confirms the server is who it says it is. TLS is specified in [RFC5246]. Here's how it goes 💅:

  1. The VNC client starts the TLS Handshake Protocol with the system named by the <host> and <port> information values.
  2. When the server certificate arrives, the hash of the key certificate gets computed with the algorithm that matches the IdHashAlgorithm parameter value. Then it's compared with the expected IdHash value (if there is one) 👀. If the certificate hash can't be verified, the client alerts the user or operator. In a normal interactive setup, the alert shows the remote system's identifying info and lets the user bail on the connection. The alert could also let the user accept the key and keep going. In a dedicated setup (like a kiosk), the system can send an alert to the remote operator, write a log entry, and run fallback behavior like showing a generic message requesting servicing 🛠️.

When you're giving identifying info for a host identified by an X.509 certificate [RFC5280] [X.509], you typically include the certificate subject, issuer, validity period, and certificate hash. The VNC client MAY verify the validity of the certificate. If the certificate's validity isn't confirmed, the alert includes a statement saying that info hasn't been verified 🙈.

  1. The client finishes setting up the TLS tunnel ✨.
  2. The VNC client sets up an RFB connection to the VNC server over the channel and authenticates using the "SecurityType" as described in [RFC6143] or other reference.

If the VNC client gets extra parameters, it MAY do a variation of these steps as long as it stays consistent with the underlying protocols. For example, it could offer another form of authentication to the VNC server. Negotiating specific TLS parameters, like cipher suite configuration, is out of scope for this document 🙅‍♀️.

The TLS protocol is backwards compatible with SSLv3. But because of known security flaws, it SHOULD NOT be used 💀.

For compatibility, when the "SecurityType" parameter value is "Secure Tunnel" (23), a VNC client MUST treat the value as a request to use "Secure Tunnel" as the "ChannelType". However, this value SHOULD NOT be supplied for the "SecurityType" parameter unless it's needed for backward compatibility. The channel has to be set up before connecting to the server, and that doesn't line up with how other security types get negotiated 🫠.

3. Security Considerations 🔐

Security is the main character here, bestie 👑. General security concerns with URI schemes are covered in [RFC3986]. For the "vnc" URI scheme, the areas to think about most are application trust, URI handling, host identification, and connection database security.

Remote desktop connectivity needs security credentials to be sent around, and those can be included in a URI. If the credentials aren't kept secure, an attacker can get into any system using them. Host addresses and connection parameters can be sensitive too, since that info can help someone plan an attack 😬.

URIs can also carry host identification info. It's super important to securely identify the remote host you're connecting to. If a user connects to an attacker's system, user data, credentials included, can get exposed 💀.

Note that the RFB protocol itself may not encrypt data. To protect data in transit, RFB should be tunneled over TLS [RFC5246], SSH [RFC4251], or another secure protocol.

Some VNC systems can be used without authentication. To protect the remote host, strong passwords or other authentication mechanisms need to be used 🔑.

3.1. Application Trust 🧐

A malicious app that gets VNC credentials through a URI or some other way can obviously misuse them 😤. To protect against this, users should only install apps from trusted sources. The integrity of app packages can be verified through digital signatures.

Apps that launch VNC clients can choose to launch only particular trusted clients, and can specify those clients through platform-specific mechanisms. Package integrity can be checked programmatically by asking the package manager for digital signatures or by using other platform-specific means.

The risk to a VNC client from a launching app is generally much lower, since the launching app won't receive credentials or data from the client. A VNC client can verify its caller through platform-specific means.

VNC clients ought not to accept potentially destructive parameters from untrusted launching apps without explicit user confirmation. For example, a client-specific parameter that runs an arbitrary command when an SSH connection used for VNC tunneling gets established is potentially destructive and high risk 🚨.

3.2. URI Handling 🔗

On a mobile or desktop, launching an app usually involves in-memory URI data transmission that the operating system facilitates and secures.

When "vnc" URIs get exchanged or used within a system, their contents might be exposed through process listings or other instrumentation. Users need to avoid putting sensitive info in "vnc" URIs that could be seen by unauthorized folks 👀.

If sensitive URI info gets exchanged across a network, like a list of connection URIs on a web page, the data needs to be encrypted in transit and only accessible to authorized users.

When an app detects potentially sensitive info in a "vnc" URI, it needs to handle it securely or throw it away. Specifically, URI data on persistent storage needs to be encrypted as described in Section 3.4.

Since "vnc" URIs may contain sensitive info, apps should avoid logging the URIs even when errors happen. Users need to avoid putting sensitive info in "vnc" URIs that are used with apps where logging is unavoidable.

Apps that process URIs in a generic way, like web browsers, might not detect that sensitive info is in a URI, and could cache or store it insecurely. It's advisable to avoid putting credentials and other sensitive info in URIs that are likely to be processed generically, unless that caching and storage is disabled or otherwise secured 🫣.

3.3. Host Identification 🪪

Without verifiable host identification, a VNC client app is vulnerable to spoofing and man-in-the-middle attacks that capture VNC or host OS credentials and user data. To prevent that, administrators SHOULD secure their VNC communications with TLS [RFC5246] or SSH [RFC4251] tunnels, or other connection mechanisms that identify remote hosts via certificate or public key. VNC clients MUST verify the respective certificates or public keys to confirm the remote host's identity.

An app that launches a VNC client via URI MAY provide a certificate hash or public key hash identifying the remote host. VNC clients that keep a connection database can also store certificate or public key data for validating a host's identity.

If you're connecting to a system identified by certificate or public key and a remote system ID hash can't be matched to available identifying data, the VNC client needs to alert the user or operator. In a typical interactive environment, the alert provides the remote system's identifying info and lets the user terminate the connection. The alert can let the user accept the info and continue establishing the connection. In a dedicated environment (like a kiosk system), the system can send an alert to the remote operator, record a log entry, and execute appropriate fallback behavior, such as displaying a generic message requesting servicing.

When providing identifying info for a host identified by an X.509 certificate [RFC5280] [X.509], the certificate subject, issuer, validity period, and certificate hash need to be included. The VNC client can verify the certificate validity. If the validity of a certificate isn't determined, the alert needs to include a statement that the info hasn't been verified.

Identifying info for a host identified by public key, like the endpoint of an SSH connection using a raw key, needs to include a hash of the key.

3.4. Connection Database Integrity 🗄️

A VNC client app and/or launching app can keep a connection database with remote host info, credentials, and/or connection parameters. Apps storing credentials need to keep them in an encrypted format, with a decryption process that requires user-supplied or device-specific data. If supported, it's advisable for apps to have a setting that disables storing credentials.

If available, the VNC client connection database can store certificate or public key data used to verify host identification. To keep a malicious URI from overriding the database, if identification info in the URI conflicts with info in the database, the user or operator needs to be alerted. In a typical interactive environment, the user can be prompted to accept the new info before the database gets updated.

4. IANA Considerations 📋

The "vnc" scheme has been registered in the "Uniform Resource Identifier (URI) Schemes" registry.

The "Remote Framebuffer Security Types", "VNC URI Connection Channel Types", "VNC URI ID Hash Algorithms", and "VNC URI Parameters" registries support elements of the scheme.

4.1. "vnc" Scheme 🌈

IANA has added the "vnc" scheme to the "Uniform Resource Identifier (URI) Schemes" registry, with the description "Remote Framebuffer Protocol" and a reference to this document. A registration template is provided in Appendix A.

The IANA schemes registry is currently located at <http://www.iana.org/assignments/uri-schemes>.

4.2. Remote Framebuffer Security Types 🛡️

This document references the existing IANA "Remote Framebuffer Security Types" registry when specifying security type options. RFB security types are supported in "vnc" URIs.

Security mechanisms integrated with VNC clients might need to change the process for setting up a connection before the security handshake described in Section 7.1.2 of [RFC6143]. Such mechanisms should be reflected in the "VNC URI Connection Channel Types" registry described in Section 4.4 of this document, rather than the "Remote Framebuffer Security Types" registry, since their use can't be negotiated by the mechanism specified in [RFC6143].

Exceptions can be made for backwards compatibility. IANA has updated the "Secure Tunnel" and "Integrated SSH" security types to refer to this document.

4.3. VNC URI Group ✨

IANA has created a "Virtual Network Computing (VNC) Uniform Resource Identifier (URI)" group 🦋. This group holds application-level, URI-related registries that are separate from the ones used by the RFB protocol itself 💖.

4.4. VNC URI Connection Channel Types 🎀

IANA has created a "VNC URI Connection Channel Types" registry inside the "Virtual Network Computing (VNC) Uniform Resource Identifier (URI)" group 🌸. It has Value, Description, and Reference columns. The initial contents are described in this document ✨. The "Secure Tunnel" and "Integrated SSH" values are copied from the RFB Security Types registry, and they look like this 👑:

Value     Description      Reference
--------  ---------------  --------------
0         Reserved         this document
1         Standard TCP     this document
23        Secure Tunnel    this document
24        Integrated SSH   this document

The maximum acceptable value is 2,147,483,647 🌈.

Future assignments to this registry should be made through the "First Come First Served" process described in [RFC5226] 💅.

4.5. VNC URI ID Hash Algorithms 🔥

IANA has created a "VNC URI ID Hash Algorithms" registry inside the "Virtual Network Computing (VNC) Uniform Resource Identifier (URI)" group 🧚. It has Value, Description, and Reference columns.

The initial hash algorithms are a subset of the algorithms in the "TLS HashAlgorithm Registry" 🫶. The initial contents look like this:

Value     Description   Reference
--------  ------------  --------------
0         Reserved      this document
1         MD5           this document
2         SHA1          this document
4         SHA256        this document

The maximum acceptable value is 2,147,483,647 ⭐.

Future assignments to this registry should be made through the "First Come First Served" process described in [RFC5226] 💜.

4.6. VNC URI Parameters 🍓

IANA has created a "VNC URI Parameters" registry inside the "VNC URI" group 🌈.

The initial contents are described in this document, and they are listed below 🦋:

+-----------------+-----------------------------+-----------------+
| Name            | Description                 | Reference       |
+-----------------+-----------------------------+-----------------+
| ConnectionName  | Name of connection profile  | this document   |
+-----------------+-----------------------------+-----------------+
| VncUsername     | VNC server username         | this document   |
+-----------------+-----------------------------+-----------------+
| VncPassword     | VNC server password         | this document   |
+-----------------+-----------------------------+-----------------+
| SecurityType    | RFB security type used      | this document   |
+-----------------+-----------------------------+-----------------+
| ChannelType     | Connection channel type     | this document   |
+-----------------+-----------------------------+-----------------+
| SshHost         | SSH server hostname or IP   | this document   |
+-----------------+-----------------------------+-----------------+
| SshPort         | SSH server port             | this document   |
+-----------------+-----------------------------+-----------------+
| SshUsername     | SSH username                | this document   |
+-----------------+-----------------------------+-----------------+
| SshPassword     | SSH password                | this document   |
+-----------------+-----------------------------+-----------------+
| IdHashAlgorithm | Hash algorithm used with    | this document   |
|                 | "IdHash" parameter          |                 |
+-----------------+-----------------------------+-----------------+
| IdHash          | Expected hash of remote     | this document   |
|                 | public key or certificate   |                 |
+-----------------+-----------------------------+-----------------+
| ColorLevel      | Client color depth/mode     | this document   |
+-----------------+-----------------------------+-----------------+
| ViewOnly        | Client is view only         | this document   |
+-----------------+-----------------------------+-----------------+
| SaveConnection  | Store connection info       | this document   |
+-----------------+-----------------------------+-----------------+

Future assignments to this registry should be made through the "First Come First Served" process described in [RFC5226] 🫶.

5. References 📚

5.1. Normative References 💖

5.2. Informative References 🔍

Appendix A. "vnc" URI Template 🦋

This template is provided for registering the "vnc" URI in the IANA "Uniform Resource Identifier (URI) Schemes" registry, as specified in [RFC7595] 💅.

Scheme name: vnc

Status: Permanent

Applications/protocols that use this scheme name: Virtual Network Computing (VNC) remote desktop applications use vnc URIs. VNC applications use the Remote Framebuffer (RFB) protocol 🖥️.

Contact: IESG <iesg@ietf.org>.

Change Controller: See the authors of this document. Change control is through the IESG on behalf of the IETF <iesg@ietf.org>.

References: This document.

Acknowledgments 🫶

Dominic Parkes and the staff of RealVNC Ltd. graciously reviewed this document and provided constructive comments 🌸.

RFB and VNC are registered trademarks of RealVNC Ltd. in the United States and in other countries 💜.

Authors' Addresses ✨

David Warden
Dell Products LP
200 Dell Way
Round Rock, TX 78682
United States

Phone: 512-728-0380
Email: David_Warden@dell.com
URI: http://www.dell.com


Iordan Iordanov
Undatech
260 Scarlet Road, Apt. 503
Toronto, ON M6N 4X6
Canada

Email: iiordanov@gmail.com

And that's the whole thing, bestie! 🌈💖

📦 where this page comes from