The "vnc" URI Scheme
RFC 7869
| Document | Type |
RFC
- Informational
(May 2016)
Was
draft-warden-appsawg-vnc-scheme
(individual)
|
|
|---|---|---|---|
| Authors | David Warden , Iordan Iordanov | ||
| Last updated | 2016-05-25 | ||
| RFC stream | Independent Submission | ||
| Formats | |||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 7869
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]