doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc7869.txt b/doc/rfc/rfc7869.txt
new file mode 100644
index 0000000..3ad766a
--- /dev/null
+++ b/doc/rfc/rfc7869.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Independent Submission                                         D. Warden
+Request for Comments: 7869                              Dell Products LP
+Category: Informational                                      I. Iordanov
+ISSN: 2070-1721                                                 Undatech
+                                                                May 2016
+
+
+                          The "vnc" URI Scheme
+
+Abstract
+
+   Virtual Network Computing (VNC) software provides remote desktop
+   functionality.  This document describes a Uniform Resource Identifier
+   (URI) scheme enabling the launch of VNC clients from other
+   applications.  The scheme specifies parameters useful in securely
+   connecting clients with remote hosts.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7869.
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://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.
+
+
+
+
+
+
+
+Warden & Iordanov             Informational                     [Page 1]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Warden & Iordanov             Informational                     [Page 2]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+1.  Introduction
+
+   Virtual Network Computing (VNC) clients are used to support remote
+   desktop connectivity based on the Remote Framebuffer (RFB) Protocol
+   [RFC6143].  It is often desirable to integrate such functionality
+   with other software.  However, the lack of a standard method for
+   specifying VNC client parameters has limited such integration.
+
+   The "vnc" Uniform Resource Identifier (URI) scheme specified in this
+   document facilitates the launch of VNC clients from applications in
+   browser-based, desktop, and mobile environments.  Using this scheme,
+   users and application vendors will be able to integrate remote
+   desktop capabilities without being tied to a particular client.
+
+   Remote desktop clients often store connection profiles in a local
+   connection database.  By associating connections specified in a URI
+   with those stored in a database, client-specific options can be
+   automatically applied to a connection launched from another
+   application, even when that application is unaware of those options.
+
+   Connections to VNC servers are often secured using mechanisms
+   including Transport Layer Security / Secure Sockets Layer (TLS/SSL)
+   tunneling [RFC5246] and Secure Shell (SSH) [RFC4251] tunneling, which
+   are outside the scope of the RFB protocol.  Defining the behavior of
+   these client-integrated security options enables their use 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].
+
+   In this document, these words will appear with that interpretation
+   only when in ALL CAPS.  Lowercase uses of these words are not to be
+   interpreted as carrying the significance described in RFC 2119.
+
+2.  The "vnc" URI Scheme
+
+2.1.  URI Scheme Syntax
+
+   The normative syntax of the "vnc" URI is defined in the <vnc-uri>
+   rule in the following syntax specification.  This specification uses
+   the Augmented Backus-Naur Form (ABNF) as described in [RFC5234].  The
+   "vnc" URI conforms to the generic URI syntax specified in [RFC3986].
+   The <userinfo>, <host>, <port>, <unreserved>, and <pct-encoded> rules
+   are defined in [RFC3986].
+
+
+
+
+Warden & Iordanov             Informational                     [Page 3]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   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 = ":" / "/" / "@" / "!" / "$" / "'"
+                        / "(" / ")" / "*" / "," / ";"
+
+   The "?", "=", and "&" characters are used to delimit VNC parameters
+   and must be percent-encoded when representing a data octet as
+   specified in [RFC3986].  Within the <vnc-params> portion of a "vnc"
+   URI, the <unreserved-symbols> do not have special meaning and need
+   not be percent-encoded when representing a data octet.
+
+   A "vnc" URI has the general form:
+
+      vnc://host:port?param1=value1&param2=value2...
+
+   The host information and each parameter value specify information
+   used in establishing or operating the remote desktop session as
+   specified in Section 2.1.1.
+
+   For example:
+
+      vnc://10.0.0.1:5901?VncPassword=secret&SecurityType=2
+
+   This example indicates a VNC connection to the host at IP "10.0.0.1"
+   on port "5901" with VNC password "secret" using the VNC
+   Authentication security type.
+
+2.1.1.  URI Parameters
+
+   A description of host information and URI parameters is provided in
+   this section.  Information on the constraints of various data types
+   is provided in Section 2.1.2.  All parameters are considered
+   optional; however, a client will not be able to connect without
+   sufficient information.
+
+   A parameter without a specified default value indicates that no
+   default value is implied by this URI scheme; however, VNC clients can
+   apply implementation-dependent default behaviors otherwise consistent
+   with this document.
+
+
+
+Warden & Iordanov             Informational                     [Page 4]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   The <userinfo> value is deprecated and processed only in an
+   implementation-specific manner.  The <userinfo> component MUST NOT be
+   generated in an environment where a client supporting an updated URI
+   format is expected to be available.  When processing a URI value from
+   an untrusted source, VNC clients SHOULD alert the user in order to
+   mitigate the risk that the URI is constructed to obscure the identity
+   of the remote host unless the URI can be validated or backwards-
+   compatibility considerations make an alert impractical.
+
+   The <host> and <port> values in the "vnc" URI specify 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     |
+   +------------+------------+-----------------------------+----------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Warden & Iordanov             Informational                     [Page 5]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   The "vnc" URI parameter values specify remote desktop connection or
+   session properties, including aspects of client operation, usability,
+   and security as specified 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     |
+   +---------------+---------+-----------------------------+----------+
+
+   o  ConnectionName, SaveConnection
+
+      "ConnectionName" is used to identify a connection profile in both
+      the launching application and VNC client.  Profiles are applied as
+      described in Section 2.2.2.  If 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.
+
+
+
+Warden & Iordanov             Informational                     [Page 6]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+      If true, "SaveConnection" indicates a connection profile should be
+      created or updated and stored in the client connection database.
+      If false, no profile should be updated or persisted.
+
+   o  VncUsername, VncPassword, SecurityType
+
+      The "SecurityType" parameter indicates 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 will use this information to determine
+      which parameters are required and establish the connection.
+
+      VNC clients can sometimes automatically negotiate a security type
+      with a server.  Specifying the security type controls the security
+      negotiation.  Specifying the security type also allows a client to
+      prompt for necessary security parameters prior to establishing a
+      connection.  Parameters may take time to enter on mobile clients
+      and could otherwise result in timeouts and/or security lockouts.
+      If the specified type is not supported by the server, 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 using the specified "SecurityType".
+      Since passwords often contain arbitrary characters, they will
+      often require percent encoding.
+
+   o  ChannelType
+
+      "ChannelType" specifies the transport stream used to carry
+      connection data.  This allows a client to initiate a connection
+      using a secure transport protocol such as SSH prior to connecting
+      to the VNC server socket.  Use of this value in the context of the
+      "Integrated SSH" and "Secure Tunnel" channel types is provided in
+      Section 2.3.
+
+   o  SshHost, SshPort, SshUsername, SshPassword
+
+      The SSH parameters are intended for use with the "Integrated SSH"
+      channel type described in Section 2.3.1.  These parameters can
+      also be used with any future SSH-based channel types.  Since
+      passwords often contain arbitrary characters, they will often
+      require percent encoding.
+
+
+
+
+
+
+
+
+
+Warden & Iordanov             Informational                     [Page 7]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   o  IdHashAlgorithm, IdHash
+
+      The "IdHashAlgorithm" and "IdHash" values are used to verify the
+      expected identity of the remote system based on its public key or
+      certificate.  Use of these values in the context of the
+      "Integrated SSH" and "Secure Tunnel" channel types is provided in
+      Section 2.3.
+
+   o  ColorLevel
+
+      The "ColorLevel" parameter specifies the color model to use for
+      data transfer and display as specified in Section 2.1.2.  If the
+      requested color model is unsupported, the behavior is
+      implementation dependent.
+
+   o  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 this mode is unsupported by the client.
+
+   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 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 supporting
+   application-specific parameters SHOULD include a distinguishing
+   prefix within the parameter name, such as the name of the application
+   package specified in source code except when precluded by
+   compatibility constraints.  For example:
+
+      vnc://?com.dell.vncclient.ScreenMode=2&
+
+   It can also be expected that clients will maintain 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 is advisable to test "vnc"
+   URIs with specific applications or consult application-specific
+   documentation.
+
+
+
+
+
+
+Warden & Iordanov             Informational                     [Page 8]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+2.1.2.  Data Types
+
+   "vnc" URIs can be percent-encoded as specified in [RFC3986] and MUST
+   be decoded.  After decoding, the following type constraints and
+   semantics apply:
+
+   o  string
+
+      Values of "string" type are UTF-encoded strings as specified in
+      [RFC3629].
+
+      The "string<hex>" subtype used in the "IdHash" consists of colon-
+      delimited ":" octets displayed in hexadecimal.  For example:
+
+         5D:D2:39:57
+
+      Comparison of "string<hex>" values SHALL be case insensitive;
+      however, the uppercase notation is preferred for readability.
+
+   o  enum
+
+      The "enum" types consist of specific enumerated subtypes and are
+      represented by their decimal value.
+
+      The "enum<rfbsec>" values represent an RFB security type included
+      in the IANA "Remote Framebuffer Security Types" registry created
+      by [RFC6143].
+
+      "enum<chan>" values represent connection channel types listed in
+      the "VNC URI Connection Channel Types" registry created by
+      Section 4.4 of this document.  Initial values are:
+
+         Value     Description
+         --------  --------------
+         1         Standard TCP
+         23        Secure Tunnel
+         24        Integrated SSH
+
+      The "Standard TCP" channel type represents a generic TCP
+      connection.  The "Secure Tunnel" and "Integrated SSH" [RFC4252]
+      channel types are described in Section 2.3.
+
+
+
+
+
+
+
+
+
+
+Warden & Iordanov             Informational                     [Page 9]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+      Values of the "enum<idhash>" parameter represent secure hash
+      algorithms in the "VNC URI Hash Algorithms" registry created by
+      Section 4.5 of this document.  The initial values include:
+
+         Value     Description
+         --------  ------------
+         1         MD5
+         2         SHA1
+         4         SHA256
+
+      The MD5 algorithm is described in [RFC1321].  The SHA-1 and
+      SHA-256 algorithms are described in [SHS].
+
+      Values of the "enum<clevel>" subtype represent a color level.  In
+      the table below, the columns have the meaning specified in
+      Section 7.4 of [RFC6143]:
+
+         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
+
+      The values are:
+
+         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" indicates 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.
+
+   o  ushort
+
+      The "ushort" values represent unsigned 16-bit integers expressed
+      in decimal digits with value between 0-65535 inclusive.
+
+
+
+
+Warden & Iordanov             Informational                    [Page 10]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   o  boolean
+
+      "boolean" values represent conditions that are true or false and
+      are represented as either "true" or "false" respectively.  For
+      maximum compatibility, clients SHOULD accept the value 1 as
+      representing true values and 0 as representing false values.
+      Clients SHOULD perform parsing of "boolean" values in a case-
+      insensitive manner.
+
+      An example "vnc" URI including several of these data types is:
+
+         vnc://localhost:5900?ConnectionName=Server&SecurityType=2&
+            IdHash=0D:3A:72:08:57:EA:4D:30&SaveConnection=false&
+
+      Note the above example should be considered to be a contiguous
+      string without line breaks or whitespace and is broken into
+      multiple lines in this document for readability.
+
+2.2.  Processing URIs
+
+   Conceptually, a "vnc" URI supports only a "VIEW" operation,
+   indicating the user wishes to view the remote desktop accessible via
+   the URI reference.
+
+   In general, when a VNC client receives a "vnc" URI, it will initiate
+   a remote desktop connection with the RFB protocol using the specified
+   host information and parameter values.  Initiating the connection
+   using a connection channel mechanism such as those specified in
+   Section 2.3 might require processing prior to establishing the RFB
+   connection.  A client MAY attempt to automatically discover or
+   negotiate appropriate connection channel, security, or other
+   parameter values.
+
+   The process for negotiating security types is specified in [RFC6143].
+   Supported connection channels could be discovered by testing channel
+   types to detect when a channel is successfully established.  To best
+   integrate with other applications, the VNC client SHOULD initiate the
+   connection with minimal or no user intervention, whenever sufficient
+   information is available and adequate security is preserved.
+
+   Host information and parameter values may be provided through
+   connection profiles.  When a parameter value is not available from
+   either a URI or a connection profile described in Section 2.2.2, the
+   default value specified in Section 2.1.1 SHOULD be applied.  If
+   available parameters are not sufficient to establish a connection,
+   the VNC client SHOULD present a session initiation data-entry screen.
+
+
+
+
+
+Warden & Iordanov             Informational                    [Page 11]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+2.2.1.  Error Handling
+
+   In a typical interactive environment, if an error prevents a session
+   from being established, the VNC client presents an error message to
+   the user.  When the message is acknowledged, the console application
+   can show a session initiation data-entry screen populated with
+   available session parameters, or it can terminate.  If an error
+   occurs after a session is successfully established that terminates
+   the connection, the VNC client presents a termination notification to
+   the user.  When the termination notification is acknowledged, the
+   client can present a reconnection prompt or terminate.
+
+   When an error occurs in a dedicated environment (such as a kiosk
+   system), the system can transmit an alert to the remote operator,
+   record a log entry, and execute appropriate fallback behavior such as
+   automatically attempting to reestablish a session or displaying a
+   generic message requesting servicing.
+
+2.2.2.  Connection Profile Matching
+
+   VNC clients MAY store remote desktop session settings in connection
+   profiles.  If the client is able to uniquely identify and associate a
+   connection request with a connection profile based on the
+   "ConnectionName" parameter value, remote host IP address, or hostname
+   / fully qualified domain name, the VNC client SHOULD apply profile
+   values for those settings that do not have values supplied in the
+   "vnc" URI.  When profile data is unavailable, the VNC client MAY
+   apply global application defaults for settings not supplied in the
+   URI and for which the scheme does not specify a default value.  The
+   VNC client MUST NOT override supplied parameters with profile values
+   or global defaults.
+
+   When the "SaveConnection" parameter value is true, within the VNC
+   client, a connection profile SHOULD be created or updated with the
+   values supplied in 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 establishes an SSH connection to a
+   host, authenticates with SSH password authentication, establishes a
+   secure tunnel to the VNC host/port, and then connects to the VNC
+   server using a supported "SecurityType".  The secure tunnel will
+   provide encryption and data integrity, while verifying the public key
+   authenticates the server.  The SSH architecture is specified in
+   [RFC4251].  The steps are detailed below:
+
+
+
+Warden & Iordanov             Informational                    [Page 12]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   1. The VNC client initiates a transport-level connection to the
+      "SshHost" on the "SshPort" specified in the parameter values with
+      a key exchange as described in [RFC4253].
+
+   2. When the VNC client receives the server key (or certificate), the
+      hash of the key (or certificate) is computed using the algorithm
+      corresponding to the "IdHashAlgorithm" parameter value and
+      compared with the expected "IdHash" value (if available).  If the
+      certificate hash cannot be verified, the client alerts the user or
+      operator.  In a typical interactive environment, the alert
+      provides the remote system's identifying information including the
+      hash value and allows the user to terminate the connection.  The
+      alert could allow the user to accept the key and continue
+      establishing the connection.  In a dedicated environment (such as
+      a kiosk system), the system can transmit an alert to the remote
+      operator, record a log entry, and execute appropriate fallback
+      behavior such as displaying a generic message requesting
+      servicing.
+
+   3. The SSH client authenticates the user using the "SshUsername" and
+      "SshPassword" parameter values according to the "password"
+      authentication mechanism described in [RFC4252].
+
+   4. The SSH client opens a TCP/IP channel as specified in [RFC4254]
+      from the local system to the system indicated by the <host> and
+      <port> information values.
+
+   5. The VNC client establishes an RFB connection to the VNC server
+      over the channel and authenticates using the "SecurityType" as
+      described in [RFC6143] or other reference.
+
+   The VNC client MAY establish the connection described in this section
+   using an external SSH client, by launching the client and then
+   connecting to a secure tunnel created between a local port and the
+   VNC server.
+
+   If the VNC client is supplied with additional parameters outside the
+   scope of this document, it MAY perform a variation of these steps
+   consistent with the underlying protocols, for example, by using
+   "publickey" SSH client authentication [RFC4252] or providing another
+   form of authentication to the VNC server.  The specific negotiation
+   of SSH parameters such as cipher suite configuration is outside the
+   scope of this document.
+
+   Many SSH clients present key hashes using MD5, and it can be expected
+   that launching applications will specify the hash be displayed in the
+   manner its users are familiar with.
+
+
+
+
+Warden & Iordanov             Informational                    [Page 13]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   For compatibility, when the "SecurityType" parameter value is
+   "Integrated SSH" (24), a VNC client MUST treat the value as a request
+   to use "Integrated SSH" as the "ChannelType".  However, this value
+   SHOULD NOT be supplied for the "SecurityType" parameter unless
+   required for backward compatibility as the channel is established
+   prior to connecting to the server and is not consistent with the
+   negotiation of other security types.
+
+2.3.2.  The "Secure Tunnel" Channel Type
+
+   The "Secure Tunnel" channel type establishes a TLS connection with a
+   remote server using certificate authentication, over which a
+   connection to the VNC server is established using a supported
+   "SecurityType".  The secure tunnel will provide encryption and data
+   integrity, while verifying the certificate authenticates the server.
+   The TLS protocol is specified in [RFC5246].  The steps are detailed
+   below:
+
+   1. The VNC client initiates the TLS Handshake Protocol with a system
+      indicated by the <host> and <port> information values.
+
+   2. When the server certificate is received, the hash of the key
+      certificate is computed using the algorithm corresponding to the
+      "IdHashAlgorithm" parameter value and compared with the expected
+      "IdHash" value (if available).  If the certificate hash cannot be
+      verified, the client alerts the user or operator.  In a typical
+      interactive environment, the alert provides the remote system's
+      identifying information and allows the user to terminate the
+      connection.  The alert could allow the user to accept the key and
+      continue establishing the connection.  In a dedicated environment
+      (such as a kiosk system), the system can transmit 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 information of a host identified by an
+      X.509 certificate [RFC5280] [X.509], the certificate subject,
+      issuer, validity period, and certificate hash is typically
+      included.  The VNC client MAY verify the validity of the
+      certificate.  If the validity of a certificate is not confirmed,
+      the alert includes a statement indicating such information has not
+      been verified.
+
+   3. The client finishes establishing the TLS tunnel.
+
+   4. The VNC client establishes an RFB connection to the VNC server
+      over the channel and authenticates using the "SecurityType" as
+      described in [RFC6143] or other reference.
+
+
+
+Warden & Iordanov             Informational                    [Page 14]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   If the VNC client is supplied with additional parameters, it MAY
+   perform a variation of these steps consistent with the underlying
+   protocols, for example, by providing another form of authentication
+   to the VNC server.  The negotiation of specific TLS parameters such
+   as cipher suite configuration is outside the scope of this document.
+
+   The TLS protocol provides backwards compatibility with SSLv3;
+   however, due to 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 required for
+   backward compatibility as the channel must be established prior to
+   connecting to the server and is not consistent with the negotiation
+   of other security types.
+
+3.  Security Considerations
+
+   General security concerns involving URI schemes are discussed in
+   [RFC3986].  In implementing support for the "vnc" URI scheme, areas
+   for particular consideration include application trust, URI handling,
+   host identification, and connection database security.
+
+   Remote desktop connectivity requires the transmission of security
+   credentials, which could be included in a URI.  If those credentials
+   are not kept secure, an attacker can gain access to any systems using
+   those credentials.  Host addresses and connection parameters might
+   also be considered sensitive, as such information can be used in
+   planning an attack.
+
+   URIs can also contain host identification information.  It is
+   important to securely identify the remote host system to which a
+   connection is established.  If a user connects to an attacker's
+   system, user data, including credentials, can be 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.
+
+
+
+
+
+
+
+
+Warden & Iordanov             Informational                    [Page 15]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+3.1.  Application Trust
+
+   A malicious application receiving VNC credentials via URI or other
+   means can obviously misuse those credentials.  To protect against
+   this, users should only install applications from trusted sources.
+   The integrity of application packages can be verified through digital
+   signatures.
+
+   Applications launching VNC clients can elect to launch only
+   particular trusted clients and can specify those clients through
+   platform-specific mechanisms.  Package integrity can be verified
+   programmatically by querying the package manager for digital
+   signatures or other platform-specific means.
+
+   The risk to a VNC client from a launching application is generally
+   much lower, since the launching application will not receive
+   credentials or data from the client.  A VNC client can verify its
+   caller thorough platform-specific means.
+
+   VNC clients ought not to accept potentially destructive parameters
+   from untrusted launching applications without explicit user
+   confirmation.  For example, a client-specific parameter that runs an
+   arbitrary command upon establishing an SSH connection used for VNC
+   tunneling is potentially destructive and high risk.
+
+3.2.  URI Handling
+
+   Within a mobile or desktop environment, application launch will
+   typically involve in-memory URI data transmission facilitated and
+   secured by the operating system.
+
+   When "vnc" URIs are exchanged or used within a system, their contents
+   might be exposed by process listings or other instrumentation.  Users
+   need to avoid including sensitive information in "vnc" URIs that
+   could be exposed to unauthorized observation.
+
+   If sensitive URI information is exchanged across a network, for
+   example, by providing a list of connection URIs in a web page, the
+   data needs to be encrypted in transit and only be accessible to
+   authorized users.
+
+   When an application detects potentially sensitive information in a
+   "vnc" URI, it needs to be handled securely or discarded.  In
+   particular, URI data on persistent storage needs to be encrypted as
+   described in Section 3.4.
+
+
+
+
+
+
+Warden & Iordanov             Informational                    [Page 16]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   Since "vnc" URIs may contain sensitive information, applications
+   should avoid logging the URIs even when errors occur.  Users need to
+   avoid including sensitive information in "vnc" URIs that are used
+   with applications where logging is unavoidable.
+
+   Applications that process URIs in a generic way, such as web
+   browsers, might not detect that sensitive information is contained in
+   a URI and could cache or store that information insecurely.  It is
+   advisable to avoid including credentials and other sensitive
+   information in URIs that are likely to be processed in a generic way
+   unless such caching and storage is disabled or otherwise secured.
+
+3.3.  Host Identification
+
+   In the absence of verifiable host identification, a VNC client
+   application is vulnerable to spoofing and man-in-the-middle attacks
+   that capture VNC or host OS credentials and user data.  To prevent
+   such attacks, administrators SHOULD secure their VNC communications
+   with TLS [RFC5246] or SSH [RFC4251] tunnels or other connection
+   mechanisms identifying 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 application launching a VNC client via URI MAY provide a
+   certificate hash or public key hash identifying the remote host.  VNC
+   clients maintaining a connection database can also store certificate
+   or public key data suitable for validating a host's identity.
+
+   If connecting to a system identified by certificate or public key and
+   a remote system ID hash cannot be matched to available identifying
+   data, the VNC client needs to alert the user or operator.  In a
+   typical interactive environment, the alert will provide the remote
+   system's identifying information and allow the user to terminate the
+   connection.  The alert can allow the user to accept the information
+   and continue establishing the connection.  In a dedicated environment
+   (such as a kiosk system), the system can transmit 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 information of 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 is not determined, the alert needs to include a statement
+   indicating such information has not been verified.
+
+
+
+
+
+
+Warden & Iordanov             Informational                    [Page 17]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   Identifying information of a host identified by public key, such as
+   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 application and/or launching application can maintain a
+   connection database containing remote host information, credentials,
+   and/or connection parameters.  Applications storing credentials need
+   to ensure they are stored in an encrypted format with a decryption
+   process requiring user-supplied or device-specific data.  If
+   supported, it is advisable for applications to have a setting
+   disabling storage of credentials.
+
+   If available, the VNC client connection database can store
+   certificate or public key data used to verify host identification.
+   To prevent a malicious URI from overriding the database, if
+   identification information in the URI conflicts with information 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
+   information prior to updating the database.
+
+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 description "Remote Framebuffer
+   Protocol" and 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 in specifying security type options.  RFB
+   security types are supported in "vnc" URIs.
+
+
+
+
+
+Warden & Iordanov             Informational                    [Page 18]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   Security mechanisms integrated with VNC clients might need to alter
+   the process by which a connection is established prior to 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, as their use cannot
+   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 contains application-level, URI-
+   related registries distinct from those used by the RFB protocol
+   itself.
+
+4.4.  VNC URI Connection Channel Types
+
+   IANA has created a "VNC URI Connection Channel Types" registry within
+   the "Virtual Network Computing (VNC) Uniform Resource Identifier
+   (URI)" group.  The registry includes Value, Description, and
+   Reference columns.  The initial contents of the registry are
+   described in this document.  The values of the "Secure Tunnel" and
+   "Integrated SSH" types are copied from the RFB Security Types
+   registry.  They are:
+
+   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 within the
+   "Virtual Network Computing (VNC) Uniform Resource Identifier (URI)"
+   group.  The registry includes Value, Description, and Reference
+   columns.
+
+
+
+
+Warden & Iordanov             Informational                    [Page 19]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   The initial hash algorithms specified are a subset of the algorithms
+   contained in the "TLS HashAlgorithm Registry".  The initial contents
+   of the registry are:
+
+   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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Warden & Iordanov             Informational                    [Page 20]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+4.6.  VNC URI Parameters
+
+   IANA has created a "VNC URI Parameters" registry within the "VNC URI"
+   group.
+
+   The initial contents are described in this document.  They are:
+
+   +-----------------+-----------------------------+-----------------+
+   | 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].
+
+
+
+
+
+
+
+
+Warden & Iordanov             Informational                    [Page 21]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+             DOI 10.17487/RFC1321, April 1992,
+             <http://www.rfc-editor.org/info/rfc1321>.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119,
+             DOI 10.17487/RFC2119, March 1997,
+             <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+             STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003,
+             <http://www.rfc-editor.org/info/rfc3629>.
+
+   [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+             Resource Identifier (URI): Generic Syntax", STD 66, RFC
+             3986, DOI 10.17487/RFC3986, January 2005,
+             <http://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+             Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
+             January 2006, <http://www.rfc-editor.org/info/rfc4251>.
+
+   [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+             Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
+             January 2006, <http://www.rfc-editor.org/info/rfc4252>.
+
+   [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+             Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
+             January 2006, <http://www.rfc-editor.org/info/rfc4253>.
+
+   [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+             Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
+             January 2006, <http://www.rfc-editor.org/info/rfc4254>.
+
+   [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
+             Specifications: ABNF", STD 68, RFC 5234,
+             DOI 10.17487/RFC5234, January 2008,
+             <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+             (TLS) Protocol Version 1.2", RFC 5246,
+             DOI 10.17487/RFC5246, August 2008,
+             <http://www.rfc-editor.org/info/rfc5246>.
+
+
+
+
+Warden & Iordanov             Informational                    [Page 22]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+   [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+             Housley, R., and W. Polk, "Internet X.509 Public Key
+             Infrastructure Certificate and Certificate Revocation List
+             (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+             <http://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC6143] Richardson, T. and J. Levine, "The Remote Framebuffer
+             Protocol", RFC 6143, DOI 10.17487/RFC6143, March 2011,
+             <http://www.rfc-editor.org/info/rfc6143>.
+
+   [SHS]     National Institute of Standards and Technology, "Secure
+             Hash Standard", NIST FIPS PUB 180-4,
+             DOI 10.6028/NIST.FIPS.180-4, August 2015.
+
+5.2.  Informative References
+
+   [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+             DOI 10.17487/RFC5226, May 2008,
+             <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and
+             Registration Procedures for URI Schemes", BCP 35, RFC 7595,
+             DOI 10.17487/RFC7595, June 2015,
+             <http://www.rfc-editor.org/info/rfc7595>.
+
+   [X.509]   ITU-T, "Information technology - Open Systems
+             Interconnection - The Directory: Public-key and attribute
+             certificate frameworks", ITU-T Recommendation X.509,
+             ISO/IEC 9594-8, 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Warden & Iordanov             Informational                    [Page 23]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+Appendix A.  "vnc" URI Template
+
+   This template is provided for registration of 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Warden & Iordanov             Informational                    [Page 24]
+
+RFC 7869                  The "vnc" URI Scheme                  May 2016
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Warden & Iordanov             Informational                    [Page 25]
+