GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7869

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7869.txt · Last modified: 2016/05/25 23:38 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki